Bitcoin Forum
March 29, 2024, 05:29:30 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Video of a Bitcoin point of sale solution using NFC for contactless payment  (Read 1057 times)
jav (OP)
Sr. Member
****
Offline Offline

Activity: 249
Merit: 251


View Profile
January 02, 2014, 08:43:53 AM
 #1

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:

Quote
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! :-)

Hive, a beautiful wallet with an app platform for Mac OS X, Android and Mobile Web. Translators wanted! iOS and OS X devs see BitcoinKit. Tweets @hivewallet. Donations appreciated at 1HLRg9C1GsfEVH555hgcjzDeas14jen2Cn.
If you want to be a moderator, report many posts with accuracy. You will be noticed.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711690170
Hero Member
*
Offline Offline

Posts: 1711690170

View Profile Personal Message (Offline)

Ignore
1711690170
Reply with quote  #2

1711690170
Report to moderator
1711690170
Hero Member
*
Offline Offline

Posts: 1711690170

View Profile Personal Message (Offline)

Ignore
1711690170
Reply with quote  #2

1711690170
Report to moderator
1711690170
Hero Member
*
Offline Offline

Posts: 1711690170

View Profile Personal Message (Offline)

Ignore
1711690170
Reply with quote  #2

1711690170
Report to moderator
kalus
Sr. Member
****
Offline Offline

Activity: 420
Merit: 263

let's make a deal.


View Profile
January 02, 2014, 11:27:40 AM
 #2

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

DC2ngEGbd1ZUKyj8aSzrP1W5TXs5WmPuiR wow need noms
jav (OP)
Sr. Member
****
Offline Offline

Activity: 249
Merit: 251


View Profile
January 02, 2014, 12:57:39 PM
 #3

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:

Quote
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.

Hive, a beautiful wallet with an app platform for Mac OS X, Android and Mobile Web. Translators wanted! iOS and OS X devs see BitcoinKit. Tweets @hivewallet. Donations appreciated at 1HLRg9C1GsfEVH555hgcjzDeas14jen2Cn.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!