Video of a Bitcoin point of sale solution using NFC for contactless payment

[jav]

Hey there! Over the last couple of days I have put together a technology demo of how a point of sale solution using Bitcoin + NFC might look like. Here is the video:

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

And this blog post has some more details: https://www.bridgewalkerapp.com/blog/2014/01/01/bitcoin-nfc-point-of-sale/ . An excerpt:

The [...] video is a technology demo of how Bitcoin might be used [...] in a point of sale setting, where a customer wants to pay contactless with his smartphone. To set the stage: In this example the merchant is using a laptop to initiate the process. She enters the price of the product - let's say 2 euros - and the software uses the current Bitcoin exchange rate to calculate a Bitcoin amount, which is then shown to the customer on an external screen together with payment instructions. The customer holds his phone close to the NFC pad and receives the payment details. In this case he uses the Bridgewalker app, where he maintains a euro balance, which can be converted to bitcoins for the purpose of transfer at a moment's notice. The app picks up the payment request and - after final confirmation by the user - sends out a Bitcoin transaction. To increase speed and especially reliability a copy of the Bitcoin transaction is also sent back to the merchant via Bluetooth. The payment is now complete (caveat: the risk of double spending - see discussion below). In the video the merchant simply receives the bitcoins via Bitcoin-Qt. But one could imagine to plug in a merchant solution like BitPay or Coinbase here, which would then convert back to euros to complete the cycle.

Feedback much appreciated! :-)

[kalus]

surprisingly fast!  would the customer have to wait until the vendor received x confirmations?

[jav]

would the customer have to wait until the vendor received x confirmations?

Hard to say in general, but I think for small value transactions it would be fine to proceed without confirmations, although some additional double spend detection heuristic still needs to be added. Some comments from the blog post:

The common wisdom so far has been, that for small in person payments the risk of accepting zero-confirmation transactions is minimal. I agree that this is probably true. Although it is only true, if the merchant receives the transaction via the Bitcoin network and therefore has some indication that it has been broadcasted widely.

In this setting the merchant receives the transaction directly from the customer, which makes it much easier for the customer to trick the merchant, by sending a conflicting transaction simultaneously to the rest of the Bitcoin network. So this is still one of the pieces missing from this solution, before it is ready for real world usage. The merchant should wait a few extra seconds (unfortunately adding extra delay) and then check with a number of highly connected Bitcoin nodes whether there are any known double spends (feature request for Blockchain.info: return the double spend info that you are collecting already via your JSON api. It would be great if the data returned for a transaction would have an extra field called "known_double_spends" or "known_conflicts" which would be simply "true" or "false" or maybe a list of conflicting transaction ids). This would, I believe, be a reasonably secure heuristic for small amounts.

[...]

As an aside: The demo above employs green addresses. Bridgewalker transactions can be recognized by their use of coins from 1MAxx46Dp3tFw933PxPwEYYGCpxYda2pyH which is why the backend displays "Verified by Bridgewalker" after receiving the transaction. So in this case the merchant knows where to complain, if anything murky should happen with the transaction afterwards.