[Bitcoin-development] Instant / contactless payments

[Bitcoin-development] Instant / contactless payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 4137 bytes --]

I just did my first contactless nfc payment with a MasterCard. It worked
very well and was quite delightful - definitely want to be doing more of
these in future. I think people will come to expect this kind of
no-friction payment experience and Bitcoin will need to match it, so here
are some notes on what's involved.

There are two aspects that can be implemented independently of each other:

1) The physical/NFC layer.
2) The risk analysis layer.

A contactless payment needs two things to work: one is a VERY fast, low
latency communication between payment device (phone in our case) and
terminal. I couldn't find actual latency specs yet but it felt like using
an Oyster card, which aims for <400msec.

The other is that obviously the payment device has to decide to sign the
transaction without any user interaction, i.e. the payment is at low risk
of being unintentional. If you nail this it can be used for one-click web
payments too.

Andreas already did some work on embedding full blown payment requests into
an NFC tag, but I think we need to switch this to being a packet based
protocol (via ISO-DEP), otherwise you can't submit the Payment/tx messages
back via NFC as well. This isn't a very complicated task and would make a
fun project for a newbie who has Android and knows some Java. The resulting
ISO-DEP protocol can be turned into a BIP without too much trouble.

The risk analysis is the more complicated part. The real value
Visa/MasterCard provide with NFC payments is not so much the tech (the
clever part is the batteryless nature of the cards rather than the
crypto/comms), but the fact that merchants are all verified and can be
fined or evicted if they abuse the system and try to steal money. Bitcoin
doesn't have anything like that.

I think we have a few options to make it safe:

1) Require some very lightweight user confirmation, like pressing the power
button to reach the lock screen and only allowing small payments. The
combination of physical proximity and pressing the power button is probably
good enough for now to avoid problems. Someone should try it out and see
how it feels.

2) Have some kind of semi-centralised merchant verification/approval
programs, like what the card networks do. The easiest way to start would be
to piggyback on the work BitPay/Coinbase do and just auto-sign if payment
amount is <X mBTC and the payment is via one of these processors. But this
is hardly in the spirit of Bitcoin and is generally unsatisfying.

3) Have some kind of decentralised reputation network. I spent some time
thinking about this, but it rapidly became very complicated and feels like
an entirely separate project that should stand alone from Bitcoin itself.
Perhaps rather than try to make a global system, social data could be
exchanged (using some fancy privacy preserving protocols?) so if your
friends have decided to trust seller X, your phone automatically trusts
them too.

4) Have the touch trigger a delayed payment and the phone tries to attract
attention to itself so the user can cancel. This way if someone tries to
swipe money out of your pocket by getting up close on a subway or
something, you have a chance to cancel. But it's quite hard for a small
device to reliably attract attention quickly and it opens up the merchant
to fraud where the user pays, leaves and then cancels the payment.
Especially it'd be useless for things like mass transit. So I think such a
system would have to be opt-in by the seller.

5) A combination of all the above.

To get the very fast light feel the actual contact period has to be quite
short, so I bet we'd need to optimise the bootup process of the Android
wallet app. Right now it does slow things like deserialising giant protocol
buffers and is just generally not optimised for startup time. Loading the
wallet, reading the payment request over NFC, checking the cert signatures,
making the trust decision, calculating a transaction, signing it, sending
it back to the recipient all in under 400 msec would be a tough (but fun)
programming challenge. Some of the steps can be parallelised and modern
phones are mostly multicore.

[-- Attachment #2: Type: text/html, Size: 4539 bytes --]

Re: [Bitcoin-development] Instant / contactless payments

[Andreas Schildbach]

I'm not sure if iso-dep is the way to go here. Afaik as soon as you pick
up the phone the connection breaks. It's ok if some people decide to let
the app do risk analysis, but you cannot force it onto users by picking
a protocol that cannot deal with manual verification. Users should
always have the choice to verify their payment without time pressure and
by holding the device of their choice at their individual viewing distance.

Besides, how do you plan to risk-analyse the memo field?

In current phone implementations, the screen must be on already for NFC
to be active. Also it must be unlocked, although I certainly hope future
OSes will allow payment apps on the lock screen, just like they allow
music players.

> To get the very fast light feel the actual contact period has to be
> quite short, so I bet we'd need to optimise the bootup process of the
> Android wallet app.

It's already very short if you can do without Android Beam, e.g. on
Android 2.3. I'd say <200 ms for an BIP21 payment request. Bootup of the
app and everything else happens after -- no need to continue contact.
Indeed most of the bootup time goes into loading complex wallets. Our
long standing plans to clean up the wallet and archieve transactions
should help. Also, if Bitcoin catches on the app will just stay in memory.

The most obvious optimization to speed up signature checking is to make
it lazy. The user can already inspect the payment while signatures are
being checked. Even transaction signing could already happen in advance,
if it can be made sure that no signed transaction "escapes" the dialog
without the users consent.

Even the current ~10 second roundtrip is a huge improvement to the
status quo. I recently tried to buy a subway ticket and it took me 7
full minutes (just for the payment process)!

Re: [Bitcoin-development] Instant / contactless payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1447 bytes --]

On Thu, Mar 6, 2014 at 12:26 PM, Andreas Schildbach
<andreas@schildbach.de>wrote:

> I'm not sure if iso-dep is the way to go here. Afaik as soon as you pick
> up the phone the connection breaks.


If the phone isn't willing to immediately authorise then it'd have to fall
back to HTTPS or Bluetooth as normal.


> Besides, how do you plan to risk-analyse the memo field?
>

I guess only the amount and destination are relevant for risk analysis.


> It's already very short if you can do without Android Beam, e.g. on
> Android 2.3.


I think IsoDep based protocols must bypass Beam - when I scan my e-passport
there's no beam animation.


> The most obvious optimization to speed up signature checking is to make
> it lazy. The user can already inspect the payment while signatures are
> being checked.


Well, for <400msec there can't be any user interaction. But checking
signatures on the payment request and constructing and signing the inputs
can all be done in parallel - you should be able to max out every core, at
least for a brief moment.


> Even the current ~10 second roundtrip is a huge improvement to the
> status quo. I recently tried to buy a subway ticket and it took me 7
> full minutes (just for the payment process)!


Then that subway kind of sucks ;) Have you been to London and used Oyster?
I think the capital wouldn't work at all without the low latency Oyster
cards. The tube would have stopped scaling some time ago.

[-- Attachment #2: Type: text/html, Size: 2428 bytes --]

Re: [Bitcoin-development] Instant / contactless payments

[Andreas Schildbach]

On 03/06/2014 02:44 PM, Mike Hearn wrote:

>     I'm not sure if iso-dep is the way to go here. Afaik as soon as you pick
>     up the phone the connection breaks.
> 
> If the phone isn't willing to immediately authorise then it'd have to
> fall back to HTTPS or Bluetooth as normal.

Ok, that would be an option.

>     Besides, how do you plan to risk-analyse the memo field?
> 
> I guess only the amount and destination are relevant for risk analysis.

The memo field (and its logical evolution, an invoice) also needs to be
verified, since its part of the contract. Imagine sitting in a
restaurant and you're being presented the bill, most people will do a
quick scan of the meals and drinks consumed (and non-malignant errors
are frequent in that business).

>     It's already very short if you can do without Android Beam, e.g. on
>     Android 2.3.
> 
> I think IsoDep based protocols must bypass Beam - when I scan my
> e-passport there's no beam animation.

Everything except Beam bypasses Beam (-:  Beam is an Android-specific
protocol. I assume it would also be possible to write an own NDEF
implementation on top of the low level NFC APIs. I want to try as soon
as I have a second NFC-capable phone, preferably Android 4.4.

>     Even the current ~10 second roundtrip is a huge improvement to the
>     status quo. I recently tried to buy a subway ticket and it took me 7
>     full minutes (just for the payment process)!
> 
> Then that subway kind of sucks ;)

You can't really blame the subway for a broken payment process.

> Have you been to London and used Oyster?

Yes, it was a complete disaster. Obtaining a ticket took even longer --
ca. 45 minutes. Boarding the train took some additional seconds,
compared to no overhead in Germany where we simply don't have any gates.

On top of that, you walk more (in tunnels) than you get driven around,
get tracked on each movement and if you want to get your (monetary)
change, you need to wait for another 45 minutes.

The upside is, when going by public transport in England I always feel
like Mr. Freeman in City 17  (-:

Re: [Bitcoin-development] Instant / contactless payments, IsoDep

[Andreas Schildbach]

On 03/06/2014 03:51 PM, Andreas Schildbach wrote:

>>     I'm not sure if iso-dep is the way to go here. Afaik as soon as you pick
>>     up the phone the connection breaks.
>>
>> If the phone isn't willing to immediately authorise then it'd have to
>> fall back to HTTPS or Bluetooth as normal.
> 
> Ok, that would be an option.

One of the first things to explore is if its possible to dispatch
different isodep applications to different apps. I know you can add an
intent filter matching action=android.nfc.action.TECH_DISCOVERED and a
custom "tech filter" android.nfc.tech.IsoDep. However, as long as there
is no mime type or similar concept, apps will always fight for access to
IsoDep endpoints. We will want to avoid that situation.

Re: [Bitcoin-development] Instant / contactless payments, IsoDep

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]

I think maybe the way you do it is to have a NDEF tag that triggers the
app, and then that starts an IsoDep protocol once opened. I *think*.


On Thu, Mar 6, 2014 at 5:55 PM, Andreas Schildbach <andreas@schildbach.de>wrote:

> On 03/06/2014 03:51 PM, Andreas Schildbach wrote:
>
> >>     I'm not sure if iso-dep is the way to go here. Afaik as soon as you
> pick
> >>     up the phone the connection breaks.
> >>
> >> If the phone isn't willing to immediately authorise then it'd have to
> >> fall back to HTTPS or Bluetooth as normal.
> >
> > Ok, that would be an option.
>
> One of the first things to explore is if its possible to dispatch
> different isodep applications to different apps. I know you can add an
> intent filter matching action=android.nfc.action.TECH_DISCOVERED and a
> custom "tech filter" android.nfc.tech.IsoDep. However, as long as there
> is no mime type or similar concept, apps will always fight for access to
> IsoDep endpoints. We will want to avoid that situation.
>
>
>
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries.  Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 2399 bytes --]

Re: [Bitcoin-development] Instant / contactless payments, IsoDep

[Andreas Schildbach]

I doubt that this is possible (with the Android API). But I'll try.


On 03/06/2014 06:00 PM, Mike Hearn wrote:
> I think maybe the way you do it is to have a NDEF tag that triggers the
> app, and then that starts an IsoDep protocol once opened. I *think*.
> 
> 
> On Thu, Mar 6, 2014 at 5:55 PM, Andreas Schildbach
> <andreas@schildbach.de <mailto:andreas@schildbach.de>> wrote:
> 
>     On 03/06/2014 03:51 PM, Andreas Schildbach wrote:
> 
>     >>     I'm not sure if iso-dep is the way to go here. Afaik as soon
>     as you pick
>     >>     up the phone the connection breaks.
>     >>
>     >> If the phone isn't willing to immediately authorise then it'd have to
>     >> fall back to HTTPS or Bluetooth as normal.
>     >
>     > Ok, that would be an option.
> 
>     One of the first things to explore is if its possible to dispatch
>     different isodep applications to different apps. I know you can add an
>     intent filter matching action=android.nfc.action.TECH_DISCOVERED and a
>     custom "tech filter" android.nfc.tech.IsoDep. However, as long as there
>     is no mime type or similar concept, apps will always fight for access to
>     IsoDep endpoints. We will want to avoid that situation.
> 
> 
> 
> 
>     ------------------------------------------------------------------------------
>     Subversion Kills Productivity. Get off Subversion & Make the Move to
>     Perforce.
>     With Perforce, you get hassle-free workflows. Merge that actually works.
>     Faster operations. Version large binaries.  Built-in WAN
>     optimization and the
>     freedom to use Git, Perforce or both. Make the move to Perforce.
>     http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>     _______________________________________________
>     Bitcoin-development mailing list
>     Bitcoin-development@lists.sourceforge.net
>     <mailto:Bitcoin-development@lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works. 
> Faster operations. Version large binaries.  Built-in WAN optimization and the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> 
> 
> 
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

Re: [Bitcoin-development] Instant / contactless payments

[Johannes Zweng]

[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]

2014-03-06 12:26 GMT+01:00 Andreas Schildbach <andreas@schildbach.de>:


> In current phone implementations, the screen must be on already for NFC
> to be active. Also it must be unlocked, although I certainly hope future
> OSes will allow payment apps on the lock screen, just like they allow
> music players.


Just a small input to this point:
On Android 4.4 the new host card emulation (HCE) feature (aka: the phone
emulates a ISO-DEP Smartcard and processes ISO7816-4 APDU commands like a
Smartcard would do) only works when the display is on, but even when the
screen is locked (can be changed with "android:requireDeviceUnlock" in
Manifest). See here for detailled specification:
http://developer.android.com/guide/topics/connectivity/nfc/hce.html

Using the HCE API on Android 4.4 also has the beauty that any app that
registers itself for HCE and sets its category to CATEGORY_PAYMENT in the
Manifest automatically shows up in Adroid's system settings under "Tap &
Pay" (where a user would expect payment applications).

[-- Attachment #2: Type: text/html, Size: 1638 bytes --]

Re: [Bitcoin-development] Instant / contactless payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 2591 bytes --]

HCE is a bit scary. It's like the card companies tried the secure element
thing, decided the security was too hard and were like "screw it, let's
just use regular apps after all". Not that we're any better :)

At any rate, Bitcoin doesn't have any need to emulate smartcards as we
don't have any pre-existing infrastructure. We can just use a regular
non-smarcard-emulation ISO-DEP protocol. The new UI in Android 4.4 provides
some way to choose the default payment app, but I think it's only intended
to disambiguate between credit card providers. Everything else gets dumped
into CATEGORY_OTHER and I dunno what happens if you have multiple Bitcoin
wallet apps doing the same thing. Worst case, we can add some
disambiguation code on top, inside the apps themselves.



On Fri, Mar 7, 2014 at 10:26 AM, Johannes Zweng <johannes@zweng.at> wrote:

>
> 2014-03-06 12:26 GMT+01:00 Andreas Schildbach <andreas@schildbach.de>:
>
>
>
>> In current phone implementations, the screen must be on already for NFC
>> to be active. Also it must be unlocked, although I certainly hope future
>> OSes will allow payment apps on the lock screen, just like they allow
>> music players.
>
>
> Just a small input to this point:
> On Android 4.4 the new host card emulation (HCE) feature (aka: the phone
> emulates a ISO-DEP Smartcard and processes ISO7816-4 APDU commands like a
> Smartcard would do) only works when the display is on, but even when the
> screen is locked (can be changed with "android:requireDeviceUnlock" in
> Manifest). See here for detailled specification:
> http://developer.android.com/guide/topics/connectivity/nfc/hce.html
>
> Using the HCE API on Android 4.4 also has the beauty that any app that
> registers itself for HCE and sets its category to CATEGORY_PAYMENT in the
> Manifest automatically shows up in Adroid's system settings under "Tap &
> Pay" (where a user would expect payment applications).
>
>
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries.  Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 3865 bytes --]

Re: [Bitcoin-development] Instant / contactless payments

[Andreas Schildbach]

On 03/07/2014 10:26 AM, Johannes Zweng wrote:

>     In current phone implementations, the screen must be on already for NFC
>     to be active. Also it must be unlocked, although I certainly hope future
>     OSes will allow payment apps on the lock screen, just like they allow
>     music players.
> 
> Just a small input to this point:
> On Android 4.4 the new host card emulation (HCE) feature (aka: the phone
> emulates a ISO-DEP Smartcard and processes ISO7816-4 APDU commands like
> a Smartcard would do) only works when the display is on, but even when
> the screen is locked (can be changed with "android:requireDeviceUnlock"
> in Manifest). See here for detailled
> specification: http://developer.android.com/guide/topics/connectivity/nfc/hce.html
> 
> Using the HCE API on Android 4.4 also has the beauty that any app that
> registers itself for HCE and sets its category to CATEGORY_PAYMENT in
> the Manifest automatically shows up in Adroid's system settings under
> "Tap & Pay" (where a user would expect payment applications).

Thanks for the pointer! Good to hear there is finally a decent
documentation for HCE.

Good news: HCE offers the required dispatch ability -- they call it AID
(Application ID).

Bad news: It seems - at least CATEGORY_PAYMENT - very credit card centric.

HCE seems to cover only the payer side. I wonder if there is also an API
for "reader emulation" which we would need for apps to support the payee
side.

Since Android 4.4 market penetration is quite far off, I suggest we
focus on the already established NFC payment protocol(s) for now, it
works pretty well. I will investigate into IsoDep and HCE and see if we
can make it enhance usability.

Interesting side note: They recommend messages transmitted via NFC to
not exceed 1 KB in order for a snappy experience. This (again) questions
usage of bulky X.509 certificates in our payment request messages.
Bitcoin Wallet currently does not sign payment requests, so I could not
try how it would feel.

Re: [Bitcoin-development] Instant / contactless payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 903 bytes --]

>
> Interesting side note: They recommend messages transmitted via NFC to
> not exceed 1 KB in order for a snappy experience. This (again) questions
> usage of bulky X.509 certificates in our payment request messages.
> Bitcoin Wallet currently does not sign payment requests, so I could not
> try how it would feel.


I think you could just put a signed PaymentRequest into an NFC tag and try
reading it from that. It's the same underlying radio tech so the transfer
speeds should be similar, I'd think.

Common X.509 certs are bigger than they need to be for sure, but a lot of
the bulk comes from the use of RSA rather than ECC. An RSA signature alone
can be 256 bytes! There's nothing that states you have to use RSA for
certificates and ECC certs are out there (Google uses one), but I think
they are harder to get hold of. I guess over time SSL will migrate to
mostly ECC (secp256r1) based certs.

[-- Attachment #2: Type: text/html, Size: 1264 bytes --]

Re: [Bitcoin-development] Instant / contactless payments

[Johannes Zweng]

[-- Attachment #1: Type: text/plain, Size: 2161 bytes --]

2014-03-07 11:23 GMT+01:00 Andreas Schildbach <andreas@schildbach.de>:


> Good news: HCE offers the required dispatch ability -- they call it AID
> (Application ID).
>

Yes, that's also something adopted from the existing Smartcard world.
Existing smartcards can contain different payment applications (for example
in Germany the "Maestro" and the "Geldkarte" application on the same card).
So the terminal can actively request one specific application within the
Smartcard.

But as Mike correctly said, we have no pre-existing infrastructure to
support. So decisions should only be based on what makes sense for the
future.


Bad news: It seems - at least CATEGORY_PAYMENT - very credit card centric.
>

I'm not sure about this. I've built several HCE test apps and tested them
with readers (and other phones used as reader) but I did not notice any
difference to using CATEGORY_OTHER (besides that the apps using
CATEGORY_PAYMENT appear in KitKat's new shiny "Tap & Pay" menu).


HCE seems to cover only the payer side. I wonder if there is also an API
> for "reader emulation" which we would need for apps to support the payee
> side.
>

You are free to implement whatever protocol you want. On the reader side
you simply do a IseDep "connect()" and send your commands with
"transceive()" (
https://developer.android.com/reference/android/nfc/tech/IsoDep.html#transceive(byte[])).
After sending the initial ISO 7816-4 "SELECT APPLICATION" command (see here
for some ISO 7816-4 doc:
http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_6_basic_interindustry_commands.aspx#chap6_11)
which triggers Android HCE routing mechanism to route all following PDUs to
your HCE app, you are free to send whatever you want.

Anything you send with "transceve()" on the sender side, will be received
within your HCE application in the "processCommandApdu" method:
https://developer.android.com/reference/android/nfc/cardemulation/HostApduService.html#processCommandApdu(byte[],
android.os.Bundle)

The only limitation is that you have a strict request/response model. The
reader terminal (or the reading phone) sends a request, the HCE phone sends
a response.

[-- Attachment #2: Type: text/html, Size: 3667 bytes --]

Re: [Bitcoin-development] Instant / contactless payments

[Brooks Boyd]

[-- Attachment #1: Type: text/plain, Size: 1295 bytes --]

On Mar 6, 2014 3:47 AM, "Mike Hearn" <mike@plan99.net> wrote:
>
> I just did my first contactless nfc payment with a MasterCard. It worked
very well and was quite delightful - definitely want to be doing more of
these in future. I think people will come to expect this kind of
no-friction payment experience and Bitcoin will need to match it, so here
are some notes on what's involved.
>
> 3) Have some kind of decentralised reputation network. I spent some time
thinking about this, but it rapidly became very complicated and feels like
an entirely separate project that should stand alone from Bitcoin itself.
Perhaps rather than try to make a global system, social data could be
exchanged (using some fancy privacy preserving protocols?) so if your
friends have decided to trust seller X, your phone automatically trusts
them too.

A reputation network might be an interesting idea, or several different
networks with different curators (to prevent complete centralization), like
how the US credit score system has three main companies who track your
score. Something like a GPG ring of trust, with addresses signing other
addresses would work well, if some sort of Stealth address or HD wallet
root was the identity gaining the reputation, then address re-use wouldn't
have to be mandatory.

[-- Attachment #2: Type: text/html, Size: 1435 bytes --]

Re: [Bitcoin-development] Instant / contactless payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

>
> if some sort of Stealth address or HD wallet root was the identity gaining
> the reputation, then address re-use wouldn't have to be mandatory.
>
The identity would be the X.520 name in the signing cert that signed the
payment request. It doesn't have to be a difficult to obtain cert. It could
even be self signed for this use case, but then you lose the security
benefits and a key rotation would delete your reputation, so in practice I
think most people would want the reputation to accrue to the name itself.

[-- Attachment #2: Type: text/html, Size: 748 bytes --]

Re: [Bitcoin-development] Instant / contactless payments

[Brooks Boyd]

[-- Attachment #1: Type: text/plain, Size: 1352 bytes --]

On Thu, Mar 6, 2014 at 11:07 AM, Mike Hearn <mike@plan99.net> wrote:

> if some sort of Stealth address or HD wallet root was the identity gaining
>> the reputation, then address re-use wouldn't have to be mandatory.
>>
> The identity would be the X.520 name in the signing cert that signed the
> payment request. It doesn't have to be a difficult to obtain cert. It could
> even be self signed for this use case, but then you lose the security
> benefits and a key rotation would delete your reputation, so in practice I
> think most people would want the reputation to accrue to the name itself.
>

That makes sense, to have self-signed certificates as a basic start, but
then is it possible to have a Bitcoin user (address) add reputation/sign
such a certificate, rather than having a central signing authority? If
there was a way for a Bitcoin user to provide feedback on a payment (ECDSA
signature from one of the addresses involved in the payment, signing an
identifier of the payment and a feedback score) such that any user can add
to the reputation with just the Bitcoin infrastructure, without having to
learn X.500 certificate signing on top of EC signatures? If there was a
standard structure for a message to be EC-signed with your Bitcoin client,
and then a distributed store of those signed messages, could that form a
reputation score?

[-- Attachment #2: Type: text/html, Size: 1915 bytes --]

Re: [Bitcoin-development] Instant / contactless payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 377 bytes --]

>
> If there was a way for a Bitcoin user to provide feedback on a payment
> (ECDSA signature from one of the addresses involved in the payment, signing
> an identifier of the payment and a feedback score)
>

Well now you're getting into the area that I said "rapidly got very
complicated".

Define bitcoin user? What stops me paying myself to accrue positive
reputation? Etc.

[-- Attachment #2: Type: text/html, Size: 704 bytes --]

Re: [Bitcoin-development] Instant / contactless payments

[Brooks Boyd]

[-- Attachment #1: Type: text/plain, Size: 1221 bytes --]

On Thu, Mar 6, 2014 at 12:12 PM, Mike Hearn <mike@plan99.net> wrote:

> If there was a way for a Bitcoin user to provide feedback on a payment
>> (ECDSA signature from one of the addresses involved in the payment, signing
>> an identifier of the payment and a feedback score)
>>
>
> Well now you're getting into the area that I said "rapidly got very
> complicated".
>
> Define bitcoin user? What stops me paying myself to accrue positive
> reputation? Etc.
>

Yes, I could see how that could get hairy; it would also need some ability
to rate those giving the feedback, such that if you generate a whole bunch
of payments to yourself, those payees don't have reputation on their own,
so their review of you as a payer isn't weighted that highly. Then you have
that ring-of-trust possibility where Alice thinks Eve is bad, so the fact
that Eve thinks Bob is good doesn't impact Alice. But if Carol thinks Eve
is good, Carol thinks Bob is good too, so Bob's reputation is different
based on who's asking, and it's the responsibility of the individual
members to maintain their own good/bad user lists. Would you think that's a
good thing or a bad thing to give the individual players that level of
control/responsibility?

[-- Attachment #2: Type: text/html, Size: 1934 bytes --]

Re: [Bitcoin-development] Instant / contactless payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 713 bytes --]

>
> it's the responsibility of the individual members to maintain their own
> good/bad user lists. Would you think that's a good thing or a bad thing to
> give the individual players that level of control/responsibility?
>

If it's explicit, I think it's a non starter and nobody will bother with
it, especially not just for instant payments.

If it's just a case of "link your wallet with your Facebook account" and
requires no more effort than that, some people might, but of course the
user experience would be rather random. Hey why did that guy in front of me
get instant payments and I had to confirm even though we bought the same
things?

I'm not a big fan of UX's that appear totally random to the user.

[-- Attachment #2: Type: text/html, Size: 1070 bytes --]

Re: [Bitcoin-development] Instant / contactless payments

[Joel Kaartinen]

[-- Attachment #1: Type: text/plain, Size: 3434 bytes --]

I think a reputation network is more complicated than is needed for
this. This can be solved by the market.

What is needed is a simple method for each individual user to mark
certain merchant as trusted. For example, if your device gets an
untrusted payment request, it'll make a small sound, light up the screen
and ask the user to authorize the payment. The user then has the choice
of adding the merchant to trust list, authorizing just a single
transaction or not paying (and perhaps adding to the user's publicly
shared untrusted list?).

This way, even lacking a trust architecture, only the first payment to a
merchant needs to take several seconds. If trust is granted, the next
payments will be swift.

The lack of chargebacks presents a clear risk to the customer, though,
so a need for a third party that can keep the merchants honest exists.
This opens up markets for transaction insurance companies. Even though
bitcoin transactions are final, if a transaction insurance company
offers to cover your losses in the event of fraudulent charge, the risk
is practically eliminated.

Such an insurance company would have a strong incentive to make sure the
merchants they insure for behave. Otherwise they'll suffer the losses. I
think this would result in an equally trustworthy but more decentralized
system than with credit cards.

- Joel

On 06.03.2014 16:20, Brooks Boyd wrote:
>
>
> On Mar 6, 2014 3:47 AM, "Mike Hearn" <mike@plan99.net
> <mailto:mike@plan99.net>> wrote:
> >
> > I just did my first contactless nfc payment with a MasterCard. It
> worked very well and was quite delightful - definitely want to be
> doing more of these in future. I think people will come to expect this
> kind of no-friction payment experience and Bitcoin will need to match
> it, so here are some notes on what's involved.
> >
> > 3) Have some kind of decentralised reputation network. I spent some
> time thinking about this, but it rapidly became very complicated and
> feels like an entirely separate project that should stand alone from
> Bitcoin itself. Perhaps rather than try to make a global system,
> social data could be exchanged (using some fancy privacy preserving
> protocols?) so if your friends have decided to trust seller X, your
> phone automatically trusts them too.
>
> A reputation network might be an interesting idea, or several
> different networks with different curators (to prevent complete
> centralization), like how the US credit score system has three main
> companies who track your score. Something like a GPG ring of trust,
> with addresses signing other addresses would work well, if some sort
> of Stealth address or HD wallet root was the identity gaining the
> reputation, then address re-use wouldn't have to be mandatory.
>
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works. 
> Faster operations. Version large binaries.  Built-in WAN optimization and the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[-- Attachment #2: Type: text/html, Size: 4815 bytes --]

Re: [Bitcoin-development] Instant / contactless payments

[Alex Kotenko]

[-- Attachment #1: Type: text/plain, Size: 1839 bytes --]

Hi Mike


Not sure if you've seen it, but here is how we do NFC right now
http://www.youtube.com/watch?v=DGOMIG9JUY8 with XBTerminal.
For now this is just an NDEF URI message with Bitcoin URI inside, and then
transaction itself propagated to the network by the phone using it's own
Internet connection. Far not ideal, but even this is supported only by
Andreas' Wallet, so we cannot move ahead alot really until other wallets
will have some support in this area.
As you see - it's taking just few seconds, most of which is manual payment
confirmation. Btw, ignore my first screen tap, where I'm selecting wallets
- it's an unlikely thing to happen IRL to have several wallets installed at
the same time.

​Also, I think many people may not know about Oyster cards, so this might
need little bit of explanation. And btw, have you been to London lately?
Oyster readers now accept contactless cards directly along with Oyster
cards itself. I wonder if eventually in future we could add bitcoin support
into that system directly, without hardware replacements.

I cannot put much into the actual protocol discussion, but I'm happy to
provide feedback on the side of actual POS implementation needed and
testbase if required.

Have an ​idea - it's a good thing to cap confirmationless payments, but the
actual cap value definition can be tricky considering Bitcoin volatility.
Inless you want to tie it to some external price definition thirdparty
service it could be tied to transaction fees. I mean - if with Bitcoin v0.9
transaction fees will become really floating, and it should eventually
reach equilibrium that will reflect some real world value. Probably a tiny
value, but probably also rather stable value. So confirmationless payment
cap may be defined as <current_average_transaction_fee>x10000.

[-- Attachment #2: Type: text/html, Size: 3121 bytes --]

Re: [Bitcoin-development] Instant / contactless payments

[Andreas Schildbach]

> Not sure if you've seen it, but here is how we do NFC right
> now http://www.youtube.com/watch?v=DGOMIG9JUY8 with XBTerminal. 

Thanks for the video! It's always good to see these things in action so
you can start believing in it.

> For now this is just an NDEF URI message with Bitcoin URI inside, and
> then transaction itself propagated to the network by the phone using
> it's own Internet connection. Far not ideal, but even this is supported
> only by Andreas' Wallet, so we cannot move ahead alot really until other
> wallets will have some support in this area.

Supporting Bluetooth is optional in the sense that if a wallet should
not support it, you will still receive the transaction via the P2P
network. So I'd say definately go for Bluetooth.

> As you see - it's taking just few seconds, most of which is manual
> payment confirmation.

I wonder about the receipt step -- are you generating a PDF on device
and sending it via NFC? This is something that could be supported by the
BIP70 payment protocol. We should try to avoid the second tap, its not
intuitive.

> And btw, have you been to London
> lately? Oyster readers now accept contactless cards directly along with
> Oyster cards itself.

Contactless cards? Last I was to London, the Oyster card was already
contactless. Have there ever been magnet-strip-based Oyster cards?

> I wonder if eventually in future we could add
> bitcoin support into that system directly, without hardware replacements.

Neat thought (-:

Re: [Bitcoin-development] Instant / contactless payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

>
> I wonder about the receipt step -- are you generating a PDF on device
> and sending it via NFC? This is something that could be supported by the
> BIP70 payment protocol. We should try to avoid the second tap, its not
> intuitive.
>

Together, the signed PaymentRequest and the transactions in the block chain
should act like a receipt: it's proof you requested payment in a certain
way, and I satisfied that payment. So it's proof of payment and the memo
field can describe what I bought.


> Contactless cards? Last I was to London, the Oyster card was already
> contactless. Have there ever been magnet-strip-based Oyster cards?
>

He means, contactless credit cards can be used too. No need to enroll for
Oyster specifically. I guess in the long run Oyster and its equivalents in
other cities (octopus etc) will be phased out.

[-- Attachment #2: Type: text/html, Size: 1253 bytes --]

Re: [Bitcoin-development] Instant / contactless payments

[Alex Kotenko]

[-- Attachment #1: Type: text/plain, Size: 2531 bytes --]

2014-03-06 16:46 GMT+00:00 Andreas Schildbach <andreas@schildbach.de>:

> Supporting Bluetooth is optional in the sense that if a wallet should
> not support it, you will still receive the transaction via the P2P
> network. So I'd say definately go for Bluetooth.
>
​Yes, it's part of the​ plan. Just again - I need to make sure we support
all major wallets. And no other wallets actually support NFC by now, not
talking about bluetooth. So I imagine we will decide and implement together
some solution here, both on the wallet and POS sides, but I will have to
keep URI method and even QR codes for backwards compatibility, and wait for
other main wallets to accept innovations before we will be able to
completely switch to it.
As I said earlier - bluetooth support for my POS is not a problem, we can
plug it in easily and make it work. Support among all hardware/software and
polished user experience - this is a main thing here really.

 I wonder about the receipt step -- are you generating a PDF on device

>  and sending it via NFC? This is something that could be supported by the
> BIP70 payment protocol. We should try to avoid the second tap, its not
> intuitive.
>
​No, I'm generating it on server and sending only URL via NFC. I think this
area will change before we launch in production. Ideally I want ​the device
to be completely autonomous, controlled on site by the merchant, probably
with an app on his phone. But right now we have a backend server that gives
merchant a dashboard with device configuration control, transactions
history, daily reconciliation data and copies of receipts. So the PDF is
sent from that server.

​We should avoid second ​tap ideally, but we need to make sure receipts and
payment proofs are usable and understandable for both payers and payees.
Right now a paperless PDF-only process is already a huge leap ahead
comparing to numerous paper receipts printed for each transaction by
existing POS systems.
Implementing proof of payment based on BIP70 payment request+transaction in
the blockchain+memo will require even bigger shift in the merchant's view
on how business runs. Also it will need additional software on his side to
actually be able to view and confirm these proofs of payment. In theory -
yes, BIP70 will create a way to implement proof of payment. In practice in
real life right now I don't see it viable, it will take time to adopt and
few intermediary steps like PDF based paperless process I've implemented.

[-- Attachment #2: Type: text/html, Size: 3940 bytes --]

Re: [Bitcoin-development] Instant / contactless payments

[Andreas Schildbach]

On 03/06/2014 07:03 PM, Alex Kotenko wrote:

>     Supporting Bluetooth is optional in the sense that if a wallet should
>     not support it, you will still receive the transaction via the P2P
>     network. So I'd say definately go for Bluetooth.
> 
> ​Yes, it's part of the​ plan. Just again - I need to make sure we
> support all major wallets. And no other wallets actually support NFC by
> now, not talking about bluetooth. So I imagine we will decide and
> implement together some solution here, both on the wallet and POS sides,
> but I will have to keep URI method and even QR codes for backwards
> compatibility, and wait for other main wallets to accept innovations
> before we will be able to completely switch to it.
> As I said earlier - bluetooth support for my POS is not a problem, we
> can plug it in easily and make it work. Support among all
> hardware/software and polished user experience - this is a main thing
> here really.

Sure, take all the time you need.

All I wanted to say is you don't need to break Bitcoin URI compatibility
in order to support direct payments via Bluetooth. It's simply an
add-on, both in the BIP21 and the BIP70 cases.

Re: [Bitcoin-development] Instant / contactless payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]

Thanks Alex!

About the video - I'm curious how your device is better than just a regular
tablet. Could you give us the elevator pitch? :)

On Thu, Mar 6, 2014 at 3:39 PM, Alex Kotenko <alexykot@gmail.com> wrote:

> I mean - if with Bitcoin v0.9 transaction fees will become really
> floating, and it should eventually reach equilibrium that will reflect some
> real world value. Probably a tiny value, but probably also rather stable
> value. So confirmationless payment cap may be defined as
> <current_average_transaction_fee>x10000.
>

I guess fees will wander up and down depending on system load rather than
real world value - but maybe you're right. That said, all wallets sync
exchange rates automatically already.

In some Star Trek future, perhaps we would want Bitcoin to be independent
of other value units. But I'm not convinced such a world will ever exist.
Arguably, a stable currency would slowly become worth more over time in
line with economic growth. But then for stable prices you would need
something like a fake currency that was "backed by" (really: represented
by) a basket of goods. Otherwise over time your rent would go up in real
terms, for good real reason.

[-- Attachment #2: Type: text/html, Size: 1678 bytes --]

Re: [Bitcoin-development] Instant / contactless payments

[Alex Kotenko]

[-- Attachment #1: Type: text/plain, Size: 879 bytes --]

2014-03-06 17:03 GMT+00:00 Mike Hearn <mike@plan99.net>:

> About the video - I'm curious how your device is better than just a
> regular tablet. Could you give us the elevator pitch? :)


sure, here:
- tougher than phone/tablet. Phone dropped on the tiled floor is likely to
die instantly. Our device is designed to survive everyday intense use and
drops on the floor also.
- cheaper than phone/tablet. Usual phone/tablet costs few hundred bucks,
our device on mass scale will be definitely cheaper than that. Maybe a
noname chinese tablet will match on price, but then again what about
reliability?
- simpler than phone/tablet. Phone app needs some basic understanding to
operate. Cheap cashier employees hired by small corner shops might find
this a challenge.
- safer than phone/tablet. No option to install random apps on it. And no
temptation to steal it from the counter.

[-- Attachment #2: Type: text/html, Size: 1935 bytes --]

Re: [Bitcoin-development] Instant / contactless payments

[Jan Vornberger]

On Thu, Mar 06, 2014 at 02:39:52PM +0000, Alex Kotenko wrote:
> Not sure if you've seen it, but here is how we do NFC right now
> http://www.youtube.com/watch?v=DGOMIG9JUY8 with XBTerminal.

Very interesting, thanks for sharing! Are the two devices on the same
wifi network in the demo? In my experience transaction propagation
through the Bitcoin network takes a couple of seconds longer on average,
so I'm surprised it's that fast here.

You probably share this view, but I just wanted to repeat, that from my
experiments, I think that sending the transaction only over the Bitcoin
network should be a rarely-used fallback. It usually takes a little
longer than you would like for a POS solution and every so often you
don't get the transaction at all until the next block. And then what do
you do? Maybe you would need to ask the customer to pay again, to get
things done now, and put the previous transaction in some kind of refund
mode, where - when you finally get it - you send it back somewhere. But
it's really a problematic corner case - but yet it will happen
occasionally with network-only propagation.

In the context of this discussion, I would also like to share a video of
a prototype system:

  https://www.youtube.com/watch?v=mguRpvf3aMc

Here shown is the (currently no longer working) Bridgewalker client, but
it is also fully compatible with Andreas' wallet. The client picks up
the payment details via NFC (as a Bitcoin URI - could and should be
updated to use payment protocol) and transmits a copy of the transaction
via Bluetooth (using the simple convention first implemented by
Andreas). One optimization I did in the Bridgewalker client is, that it
already opens the Bluetooth connection when presenting the user with the
confirmation dialog. This results in a little additional speed-up, as
the connection is already "warmed up", when the user confirms. All code
of this prototype is open source, as is the Bridgewalker client.

From my testing, I can say that NFC for getting the payment details +
Bluetooth for transmitting the transaction back works well. I'm a bit
skeptical about using NFC also for the back-channel, but maybe for cases
where there is no additional user confirmation it could work.

One problem with Bluetooth I see is, that it seems to be mostly turned
off by users and many seem to perceive it as "insecure", to have it
active, as a result of earlier Bluetooth hacks. So I'm not sure if that
will turn out to be a problem for usability when rolled-out in practice.

Re: [Bitcoin-development] Instant / contactless payments

[Alex Kotenko]

[-- Attachment #1: Type: text/plain, Size: 5155 bytes --]

2014-03-08 8:52 GMT+00:00 Jan Vornberger <jan@uos.de>:
​​

> On Thu, Mar 06, 2014 at 02:39:52PM +0000, Alex Kotenko wrote:
> > Not sure if you've seen it, but here is how we do NFC right now
> > http://www.youtube.com/watch?v=DGOMIG9JUY8 with XBTerminal.
>
> Very interesting, thanks for sharing! Are the two devices on the same
> wifi network in the demo? In my experience transaction propagation
> through the Bitcoin network takes a couple of seconds longer on average,
> so I'm surprised it's that fast here.
>
No, devices on this video are not on the same network, and even if they
would - I cannot control what ​​remote hosts my phone would connect to, so
transaction may anyway travel around the globe before coming to the POS
even if they would be on one LAN.
As for transaction times - I'd say it varies. ​From my extensive testing
most of transactions usually come through within 2-5 seconds, but roughly
one in ten transactions may take more time, sometimes much more time.


You probably share this view, but I just wanted to repeat, that from my
> experiments, I think that sending the transaction only over the Bitcoin
> network should be a rarely-used fallback. It usually takes a little
> longer than you would like for a POS solution and every so often you
> don't get the transaction at all until the next block. And then what do
> you do? Maybe you would need to ask the customer to pay again, to get
> things done now, and put the previous transaction in some kind of refund
> mode, where - when you finally get it - you send it back somewhere. But
> it's really a problematic corner case - but yet it will happen
> occasionally with network-only propagation.
>
​Yes, ​I'm certain about that we need to switch to BIP70 asap. As I said
earlier - support among the wallets is the biggest problem here really.
Only Andreas' Wallet supports it right now AFAIK, and even in there it's
only as "LABS feature", so will be turned off for most of users.


In the context of this discussion, I would also like to share a video of
> a prototype system:
>
>   https://www.youtube.com/watch?v=mguRpvf3aMc
>
> Here shown is the (currently no longer working) Bridgewalker client, but
> it is also fully compatible with Andreas' wallet. The client picks up
> the payment details via NFC (as a Bitcoin URI - could and should be
> updated to use payment protocol) and transmits a copy of the transaction
> via Bluetooth (using the simple convention first implemented by
> Andreas). One optimization I did in the Bridgewalker client is, that it
> already opens the Bluetooth connection when presenting the user with the
> confirmation dialog. This results in a little additional speed-up, as
> the connection is already "warmed up", when the user confirms. All code
> of this prototype is open source, as is the Bridgewalker client.
>
Yes, I've seen this demonstration, I think it was on reddit about two
month​​ ago. Looks interesting, but by that time most of my client software
was already done, so I couldn't really use this.



> >From my testing, I can say that NFC for getting the payment details +
> Bluetooth for transmitting the transaction back works well. I'm a bit
> skeptical about using NFC also for the back-channel, but maybe for cases
> where there is no additional user confirmation it could work.

​NFC
​as ​
back channel
​definitely ​
will not work
​. Mike proposed something ​like a threshold to define minimal amount
available for spending without confirmation, but I don't see this thing
becoming widely used any time soon, and before that we will need to have
"confirm" button tap.


One problem with Bluetooth I see is, that it seems to be mostly turned
> off by users and many seem to perceive it as "insecure", to have it
> active, as a result of earlier Bluetooth hacks. So I'm not sure if that
> will turn out to be a problem for usability when rolled-out in practice.
>
Yes, this is a problem, I think bluetooth is offline on many devices, and
keeping it on all the time will harm security (if not real security, then
at least perceived by users) and also harm battery life, which will be seen
as huge problem by the users.
​Would be great to be ​able to control BT state automatically from within
the wallet app with user permission given once on installation time, but
not sure if it's possible in Android.



>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries.  Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 9220 bytes --]

Re: [Bitcoin-development] Instant / contactless payments

[Andreas Schildbach]

On 03/10/2014 04:09 PM, Alex Kotenko wrote:

> ​Yes, ​I'm certain about that we need to switch to BIP70 asap. As I said
> earlier - support among the wallets is the biggest problem here really.
> Only Andreas' Wallet supports it right now AFAIK, and even in there it's
> only as "LABS feature", so will be turned off for most of users.

Just a small clarification here. Bitcoin Wallet supports the customer
side of the protocol since 2011, without any "Labs enabling"! This means
you've got an install base of half a million devices that you can
interoperate with. Sure, a lot of users will have Bluetooth switched
off. The UI flow to enable it while paying is pretty smooth though.

The merchant side used to have the Labs enabling but this is gone since
a few weeks.

Re: [Bitcoin-development] Instant / contactless payments

[Alex Kotenko]

[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]

Ah, I see, so it's only payee who has to enable it, payer side is on by
default. Then fine, situation is better than I thought. We'll look at
implementing BIP70 asap.

Best regards,
Alex Kotenko


2014-03-10 19:28 GMT+00:00 Andreas Schildbach <andreas@schildbach.de>:

> On 03/10/2014 04:09 PM, Alex Kotenko wrote:
>
> > ​Yes, ​I'm certain about that we need to switch to BIP70 asap. As I said
> > earlier - support among the wallets is the biggest problem here really.
> > Only Andreas' Wallet supports it right now AFAIK, and even in there it's
> > only as "LABS feature", so will be turned off for most of users.
>
> Just a small clarification here. Bitcoin Wallet supports the customer
> side of the protocol since 2011, without any "Labs enabling"! This means
> you've got an install base of half a million devices that you can
> interoperate with. Sure, a lot of users will have Bluetooth switched
> off. The UI flow to enable it while paying is pretty smooth though.
>
> The merchant side used to have the Labs enabling but this is gone since
> a few weeks.
>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 2823 bytes --]

Re: [Bitcoin-development] Instant / contactless payments

[Troy Benjegerdes]

On Thu, Mar 06, 2014 at 10:45:31AM +0100, Mike Hearn wrote:
> I just did my first contactless nfc payment with a MasterCard. It worked
> very well and was quite delightful - definitely want to be doing more of
> these in future. I think people will come to expect this kind of
> no-friction payment experience and Bitcoin will need to match it, so here
> are some notes on what's involved.
> 
> There are two aspects that can be implemented independently of each other:
> 
> 1) The physical/NFC layer.
> 2) The risk analysis layer.
> 
> A contactless payment needs two things to work: one is a VERY fast, low
> latency communication between payment device (phone in our case) and
> terminal. I couldn't find actual latency specs yet but it felt like using
> an Oyster card, which aims for <400msec.

What matters more than the latency is the *variability*. I would spec this
system for no less than 200ms, and no more than 250ms to be 'standard'.

> ..... so I bet we'd need to optimise the bootup process of the Android
> wallet app. Right now it does slow things like deserialising giant protocol
> buffers and is just generally not optimised for startup time. Loading the
> wallet, reading the payment request over NFC, checking the cert signatures,
> making the trust decision, calculating a transaction, signing it, sending
> it back to the recipient all in under 400 msec would be a tough (but fun)
> programming challenge. Some of the steps can be parallelised and modern
> phones are mostly multicore.

If you have to invoke a java/ios/etc app you are never going to be consistent,
however if you have a GPL linux kernel module (like I proposed for my still
hypothetical 7coin), you should have no trouble meeting those specs. 

I'd like to be able to load my java app, tell it to put $50 on my 'instant'/nfc
wallet, and then let the kernel module spend out the $50 whenever the phone 
gets swiped by somehting.

If you do this right, every device has a well-known payment address for it's
'instant' wallet, and it should be trivial for merchants to just look at the
blockchain and confirm the instant wallet has a sufficient balance to cover
the transaction.

One more comment... having a bitcoin payment application 'check certs' seems
like a great way to ensure that Visa maintains their market share. 

If it's my phone, and I press the hardware payment button, and I only put 
$50 on it, I frankly don't care if there's a cert or not. The last thing I
want is a 'certificate validation error' when I'm trying to buy a soda.

----------------------------------------------------------------------------
Troy Benjegerdes                 'da hozer'                  hozer@hozed.org
7 elements      earth::water::air::fire::mind::spirit::soul        grid.coop

      Never pick a fight with someone who buys ink by the barrel,
         nor try buy a hacker who makes money by the megahash

Re: [Bitcoin-development] Instant / contactless payments

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]

>
> I just did my first contactless nfc payment with a MasterCard. It worked
> very well and was quite delightful - definitely want to be doing more of
> these in future.
>

A bit more competitive intelligence - turns out that the experience isn't
quite so good after all. After trying a few more times to use contactless
payments, I found it has a ~75% failure rate based on my usage.

By far the biggest problem is also the most predictable - it's very common
here for merchants to require minimum payment sizes before they'll accept
credit cards, often quite high, like 20 CHF or more. But the PIN-less mode
only works for payments below a certain threshold, I haven't quite figured
out what it is yet, but in the UK it's 20 GBP so maybe it's about 30 CHF.
So there turns out to be an incredibly thin price range in which the simple
touch-to-pay system actually works. Most of the time, either they:

a) Reject cards entirely because the payment is too small
b) Don't have the right hardware, or the hardware just mysteriously fails
to work.
c) Require a PIN because the payment is too large

I'm sure Bitcoin can do better than this.

[-- Attachment #2: Type: text/html, Size: 1519 bytes --]

Re: [Bitcoin-development] Instant / contactless payments

[Jean-Paul Kogelman]

[-- Attachment #1: Type: text/plain, Size: 2197 bytes --]


Just to add some more numbers, in Canada, the maximum is $50 and I've used it for transactions of $5, even less.

I use it every day to pay for breakfast and it works through my wallet, even with multiple NFC enabled cards in there (though not overlapping). The experience is quite smooth; simply tap my wallet on the POS and a few seconds later it's approved.

jp

On Mar 10, 2014, at 9:04 AM, Mike Hearn <mike@plan99.net> wrote:

>> I just did my first contactless nfc payment with a MasterCard. It worked very well and was quite delightful - definitely want to be doing more of these in future.
> 
> A bit more competitive intelligence - turns out that the experience isn't quite so good after all. After trying a few more times to use contactless payments, I found it has a ~75% failure rate based on my usage.
> 
> By far the biggest problem is also the most predictable - it's very common here for merchants to require minimum payment sizes before they'll accept credit cards, often quite high, like 20 CHF or more. But the PIN-less mode only works for payments below a certain threshold, I haven't quite figured out what it is yet, but in the UK it's 20 GBP so maybe it's about 30 CHF. So there turns out to be an incredibly thin price range in which the simple touch-to-pay system actually works. Most of the time, either they:
> 
> a) Reject cards entirely because the payment is too small
> b) Don't have the right hardware, or the hardware just mysteriously fails to work.
> c) Require a PIN because the payment is too large
> 
> I'm sure Bitcoin can do better than this.
> 
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[-- Attachment #2: Type: text/html, Size: 3232 bytes --]

Re: [Bitcoin-development] Instant / contactless payments

[Alex Kotenko]

[-- Attachment #1: Type: text/plain, Size: 3425 bytes --]

It heavily depends on where you use it. Here in UK any card payments are
often limited to minimum of £5 in small shops that have heavy transaction
fees burden and low margins. Big networks with more resources often let you
pay as little as you want by card, and they more often have NFC enabled POS
devices.
So it's not an NFC or POS limit, but a business decision for these small
merchants. Bitcoin can address this issue for sure, but this doesn't
concern NFC.
​​


2014-03-10 16:14 GMT+00:00 Jean-Paul Kogelman <jeanpaulkogelman@me.com>:

>
> Just to add some more numbers, in Canada, the maximum is $50 and I've used
> it for transactions of $5, even less.
>
> I use it every day to pay for breakfast and it works through my wallet,
> even with multiple NFC enabled cards in there (though not overlapping). The
> experience is quite smooth; simply tap my wallet on the POS and a few
> seconds later it's approved.
>
> jp
>
> On Mar 10, 2014, at 9:04 AM, Mike Hearn <mike@plan99.net> wrote:
>
> I just did my first contactless nfc payment with a MasterCard. It worked
>> very well and was quite delightful - definitely want to be doing more of
>> these in future.
>>
>
> A bit more competitive intelligence - turns out that the experience isn't
> quite so good after all. After trying a few more times to use contactless
> payments, I found it has a ~75% failure rate based on my usage.
>
> By far the biggest problem is also the most predictable - it's very common
> here for merchants to require minimum payment sizes before they'll accept
> credit cards, often quite high, like 20 CHF or more. But the PIN-less mode
> only works for payments below a certain threshold, I haven't quite figured
> out what it is yet, but in the UK it's 20 GBP so maybe it's about 30 CHF.
> So there turns out to be an incredibly thin price range in which the simple
> touch-to-pay system actually works. Most of the time, either they:
>
> a) Reject cards entirely because the payment is too small
> b) Don't have the right hardware, or the hardware just mysteriously fails
> to work.
> c) Require a PIN because the payment is too large
>
> I'm sure Bitcoin can do better than this.
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 5378 bytes --]