Author: Jan Vornberger 2015-02-22 19:08:39
Published on: 2015-02-22T19:08:39+00:00
A developer is working on a Bitcoin point of sale terminal based on a Raspberry Pi that displays QR codes but also provides payment requests via NFC. The terminal can receive the sender's transaction via Bluetooth, meaning the sender can be completely offline while only the terminal needs an internet connection. The typical scenario envisioned involves the customer tapping their smartphone or smartwatch on the NFC pad, confirming the transaction on their device, and then completing the transaction via Bluetooth and/or the phone's internet connection. The developer has provided a prototype in action in a video. The implementation uses Schildbach's Bitcoin Wallet and custom extensions of the wallet that are not yet standard, particularly the Bluetooth functionality. The developer aims to document their experience implementing NFC and offline payments and hopes to move the discussion forward around standardizing some of this stuff. The work of Andy Schroder around his Bitcoin Fluid Dispenser follows along the same lines, so his proposed TBIP74 and TBIP75 are relevant here as well.The developer explains why they decided to go with the combination of NFC and Bluetooth over just NFC or Bluetooth alone. They feel that the option to tap the phone and establish a Bluetooth connection is the nicest UX. However, many users have Bluetooth turned off, which can result in additional UI dialogs popping up, asking the user to turn on Bluetooth. Most Bitcoin wallets with NFC support make use of NDEF (NFC Data Exchange Format), which defines a number of record types such as 'URI' and 'Mime Type.' A common way of using NFC with Bitcoin is to create a URI record that contains a Bitcoin URI. Beyond that, Schildbach's wallet supports the mime type record, which is set to 'application/bitcoin-paymentrequest', and the rest of the NFC data is a complete BIP70 payment request. The developer lists several scenarios for handling transactions via QR code, NFC, Bluetooth, BIP70 details fetched via HTTP, and BIP70 details fetched via Bluetooth. The developer has played around with NFC URI records vs. providing the complete BIP70 payment request via NFC and has found that the latter was fairly fragile. They have switched to using the NFC URI record instead and have the phone fetch the BIP70 payment request via Bluetooth afterwards. The terminal is currently doing what scenarios 6 and 7 describe: fetching BIP70 details via Bluetooth and posting transactions via Bluetooth. TBIP75 proposes changing 'bt' to 'r1' as part of a more generic approach to numbering different sources for the BIP70 payment request. The developer likes this proposal and expresses their vote for it. A wallet should attempt all or multiple of the provided mechanisms in parallel and go with whatever completes first. TBIP75 also proposes including an additional 'h' parameter, which would be a hash of the BIP70 payment request, preventing a MITM attack on the Bluetooth channel even if the BIP70 payment request isn't signed.
Updated on: 2023-06-09T17:42:55.295597+00:00