{"type":"rich","version":"1.0","author_name":"npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3c","author_url":"https://nostr.ae/npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3c","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-02-22\n📝 Original message:On 02/22/2015 02:37 PM, Andy Schroder wrote:\n\u003e I'd like to see some discussion too about securing the bluetooth\n\u003e connection. Right now it is possible for an eavesdropper to monitor the\n\u003e data transferred. \n\nYes, this should be a prerequisite issue to all others.\n\n\u003e I'd personally like to see if wrapping the current\n\u003e connection with SSL works or if we can run https over a bluetooth\n\u003e socket. \n\nThere is no reason to add this significant complexity. The purpose of\nSSL/TLS is to establish privacy over a *public* channel. But to do so\nrequires verification by the user of the merchant's public certificate.\nOnce we rely on the channel being *private*, the entire SSL process is\nunnecessary.\n\nPresumably we would not want to require PKI for privacy, since that's a\nbit of a contradiction. But if one wants to do this NFC is not required,\nsince the private session can be established over the public (Bluetooth)\nnetwork.\n\n\u003e There was some criticism of this, but I don't think it has been\n\u003e tested to know if it is really a problem or not. If we just run https\n\u003e over bluetooth, then a lot of my concerns about the message header\n\u003e inconsistencies will go away and the connection will also be secure. We\n\u003e don't have to reinvent anything.\n\u003e \n\u003e \n\u003e \n\u003e Andy Schroder\n\u003e \n\u003e On 02/22/2015 02:08 PM, Jan Vornberger wrote:\n\u003e\u003e Hi everyone,\n\u003e\u003e\n\u003e\u003e I am working on a Bitcoin point of sale terminal based on a Raspberry\n\u003e\u003e Pi, which\n\u003e\u003e displays QR codes, but also provides payment requests via NFC. It can\n\u003e\u003e optionally\n\u003e\u003e receive the sender's transaction via Bluetooth, so if the sender wallet\n\u003e\u003e supports it, the sender can be completely offline. Only the terminal\n\u003e\u003e needs an\n\u003e\u003e internet connection.\n\u003e\u003e\n\u003e\u003e Typical scenario envisioned: Customer taps their smartphone (or maybe\n\u003e\u003e smartwatch\n\u003e\u003e in the future) on the NFC pad, confirms the transaction on their phone\n\u003e\u003e (or smartwatch) and the transaction completes via Bluetooth and/or the\n\u003e\u003e phone's\n\u003e\u003e internet connection.\n\u003e\u003e\n\u003e\u003e You can see a prototype in action here:\n\u003e\u003e\n\u003e\u003e    https://www.youtube.com/watch?v=P7vKHMoapr8\n\u003e\u003e\n\u003e\u003e The above demo uses a release version of Schildbach's Bitcoin Wallet,\n\u003e\u003e so it\n\u003e\u003e works as shown today. However, some parts - especially the Bluetooth\n\u003e\u003e stuff - are\n\u003e\u003e custom extensions of Schildbach's wallet which are not yet standard.\n\u003e\u003e\n\u003e\u003e I'm writing this post to document my experience implementing NFC and\n\u003e\u003e offline\n\u003e\u003e payments and hope to move the discussion forward around standardizing\n\u003e\u003e some of\n\u003e\u003e this stuff. Andy Schroder's work around his Bitcoin Fluid Dispenser [1,2]\n\u003e\u003e follows along the same lines, so his proposed TBIP74 [3] and TBIP75\n\u003e\u003e [4] are\n\u003e\u003e relevant here as well.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ## NFC vs Bluetooth vs NFC+Bluetooth ##\n\u003e\u003e\n\u003e\u003e Before I get into the implementation details, a few words for why I\n\u003e\u003e decided to\n\u003e\u003e go with the combination of NFC and Bluetooth:\n\u003e\u003e\n\u003e\u003e Doing everything via NFC is an interesting option to keep things\n\u003e\u003e simple, but the\n\u003e\u003e issue is, that one usually can't maintain the connection while the\n\u003e\u003e user confirms\n\u003e\u003e the transaction (as they take the device back to press a button or\n\u003e\u003e maybe enter a\n\u003e\u003e PIN). So there are three options:\n\u003e\u003e\n\u003e\u003e 1. Do a \"double tap\": User taps, takes the device back, confirms, then\n\u003e\u003e taps\n\u003e\u003e again to transmit the transaction. (I think Google Wallet does\n\u003e\u003e something like\n\u003e\u003e this.)\n\u003e\u003e\n\u003e\u003e 2. Confirm beforehand: User confirms, then taps and everything can\n\u003e\u003e happen in one\n\u003e\u003e go. The disadvantage is, that you confirm the transaction before you\n\u003e\u003e have seen\n\u003e\u003e the details. (I believe Google Wallet can also work this way.)\n\u003e\u003e\n\u003e\u003e 3. Tap the phone, then establish a Bluetooth connection which allows\n\u003e\u003e you to do\n\u003e\u003e all necessary communication even if the user takes the device back.\n\u003e\u003e\n\u003e\u003e I feel that option 3 is the nicest UX, so that is what I am focusing\n\u003e\u003e on right\n\u003e\u003e now, but there are pros and cons to all options. One disadvantage of\n\u003e\u003e option 3 in\n\u003e\u003e practice is, that many users - in my experience - have Bluetooth\n\u003e\u003e turned off, so\n\u003e\u003e it can result in additional UI dialogs popping up, asking the user to\n\u003e\u003e turn on\n\u003e\u003e Bluetooth.\n\u003e\u003e\n\u003e\u003e Regarding doing everything via Bluetooth or maybe BLE: I have been\n\u003e\u003e following the\n\u003e\u003e work that Airbitz has done around that, but personally I prefer the NFC\n\u003e\u003e interaction of \"I touch what I want to pay\" rather than \"a payment\n\u003e\u003e request comes\n\u003e\u003e to me through the air and I figure out whether it is meant for me/is\n\u003e\u003e legitimate\".\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ## NFC data formats ##\n\u003e\u003e\n\u003e\u003e A bit of background for those who are not that familiar with NFC: Most\n\u003e\u003e Bitcoin\n\u003e\u003e wallets with NFC support make use of NDEF (NFC Data Exchange Format)\n\u003e\u003e as far as I\n\u003e\u003e am aware (with CoinBlesk being an exception, which uses host-based card\n\u003e\u003e emulation, if I understand it correctly). NDEF defines a number of\n\u003e\u003e record types,\n\u003e\u003e among them 'URI' and 'Mime Type'.\n\u003e\u003e\n\u003e\u003e A common way of using NFC with Bitcoin is to create a URI record that\n\u003e\u003e contains a\n\u003e\u003e Bitcoin URI. Beyond that Schildbach's wallet (and maybe others?) also\n\u003e\u003e support\n\u003e\u003e the mime type record, which is then set to\n\u003e\u003e 'application/bitcoin-paymentrequest'\n\u003e\u003e and the rest of the NFC data is a complete BIP70 payment request.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ## Implementation ##\n\u003e\u003e\n\u003e\u003e To structure the discussion a little bit, I have listed a number of\n\u003e\u003e scenarios to\n\u003e\u003e consider below. Not every possible combination is listed, but it\n\u003e\u003e should cover a\n\u003e\u003e bit of everything.\n\u003e\u003e\n\u003e\u003e Scenarios:\n\u003e\u003e\n\u003e\u003e 1) Scan QR code, transmit transaction via Bitcoin network\n\u003e\u003e     Example QR code: bitcoin:1asdf...?amount=42\n\u003e\u003e\n\u003e\u003e 2) Touch NFC pad, transmit transaction via Bitcoin network\n\u003e\u003e     Example NFC URI: bitcoin:1asdf...?amount=42\n\u003e\u003e\n\u003e\u003e 3) Scan QR code, fetch BIP70 details via HTTP, post transaction via HTTP\n\u003e\u003e     Example QR code:\n\u003e\u003e bitcoin:1asdf...?amount=42\u0026r=https://example.org/bip70paymentrequest\n\u003e\u003e\n\u003e\u003e 4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via HTTP\n\u003e\u003e     Example NFC URI:\n\u003e\u003e bitcoin:1asdf...?amount=42\u0026r=https://example.org/bip70paymentrequest\n\u003e\u003e\n\u003e\u003e 5) Touch NFC pad, receive BIP70 details directly, post transaction via\n\u003e\u003e HTTP\n\u003e\u003e     Example NFC MIME record: application/bitcoin-paymentrequest +\n\u003e\u003e BIP70 payment request\n\u003e\u003e\n\u003e\u003e 6) Scan QR code, fetch BIP70 details via Bluetooth, post transaction\n\u003e\u003e via Bluetooth\n\u003e\u003e     Example QR code: bitcoin:1asdf...?amount=42\u0026bt=1234567890AB\n\u003e\u003e     Payment request has 'payment_url' set to 'bt:1234567890AB'\n\u003e\u003e\n\u003e\u003e 7) Touch NFC pad, fetch BIP70 details via Bluetooth, post transaction\n\u003e\u003e via Bluetooth\n\u003e\u003e     Example NFC URI: bitcoin:1asdf...?amount=42\u0026bt=1234567890AB\n\u003e\u003e     Payment request has 'payment_url' set to 'bt:1234567890AB'\n\u003e\u003e\n\u003e\u003e Scenarios 1 and 2 are basically the 'legacy'/pre-BIP70 approach and I\n\u003e\u003e am just\n\u003e\u003e listing them here for comparison. Scenario 3 is what is often in use\n\u003e\u003e now, for\n\u003e\u003e example when using a checkout screen by BitPay or Coinbase.\n\u003e\u003e\n\u003e\u003e I played around with both scenarios 4 and 5, trying to decide whether\n\u003e\u003e I should\n\u003e\u003e use an NFC URI record or already provide the complete BIP70 payment\n\u003e\u003e request via\n\u003e\u003e NFC.\n\u003e\u003e\n\u003e\u003e My experience here has been, that the latter was fairly fragile in my\n\u003e\u003e setup\n\u003e\u003e (Raspberry Pi, NFC dongle from a company called Sensor ID, using\n\u003e\u003e nfcpy). I tried\n\u003e\u003e with signed payment requests that were around 4k to 5k and the\n\u003e\u003e transfer would\n\u003e\u003e often not complete if I didn't hold the phone perfectly in place. So I\n\u003e\u003e quickly\n\u003e\u003e switched to using the NFC URI record instead and have the phone fetch\n\u003e\u003e the BIP70\n\u003e\u003e payment request via Bluetooth afterwards. Using this approach the\n\u003e\u003e amount of data\n\u003e\u003e is small enough that it's usually 'all or nothing' and that seems more\n\u003e\u003e robust to\n\u003e\u003e me.\n\u003e\u003e\n\u003e\u003e That said, I continue to have problems with the NFC stack that I'm\n\u003e\u003e using, so it\n\u003e\u003e might just be my NFC setup that is causing these problems. I will\n\u003e\u003e probably give\n\u003e\u003e the NXP NFC library a try next (which I believe is also the stack that\n\u003e\u003e is used\n\u003e\u003e by Android). Maybe I have more luck with that approach and could then\n\u003e\u003e switch to\n\u003e\u003e scenario 5.\n\u003e\u003e\n\u003e\u003e Scenarios 6 and 7 is what the terminal is doing right now. The 'bt'\n\u003e\u003e parameter is\n\u003e\u003e the non-standard extension of Andreas' wallet that I was mentioning.\n\u003e\u003e TBIP75\n\u003e\u003e proposes to change 'bt' into 'r1' as part of a more generic approach of\n\u003e\u003e numbering different sources for the BIP70 payment request. I think\n\u003e\u003e that is a\n\u003e\u003e good idea and would express my vote for this proposal. So the QR code\n\u003e\u003e or NFC URI\n\u003e\u003e would then look something like this:\n\u003e\u003e\n\u003e\u003e   \n\u003e\u003e bitcoin:1asdf...?amount=42\u0026r=https://example.org/bip70\u0026r1=bt:1234567890AB/resource\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e In addition the payment request would need to list additional\n\u003e\u003e 'payment_url's. My\n\u003e\u003e proposal would be to do something like this:\n\u003e\u003e\n\u003e\u003e      message PaymentDetails {\n\u003e\u003e          ...\n\u003e\u003e          optional string payment_url = 6;\n\u003e\u003e          optional bytes merchant_data = 7;\n\u003e\u003e          repeated string additional_payment_urls = 8;\n\u003e\u003e            // ^-- new; to hold things like 'bt:1234567890AB'\n\u003e\u003e      }\n\u003e\u003e\n\u003e\u003e TBIP75 proposes to just change 'optional string payment_url' into\n\u003e\u003e 'repeated\n\u003e\u003e string payment_url'. If this isn't causing any problems (and hopefully\n\u003e\u003e not too\n\u003e\u003e much confusion?) I guess that would be fine too.\n\u003e\u003e\n\u003e\u003e In my opinion a wallet should then actually attempt all or multiple of\n\u003e\u003e the\n\u003e\u003e provided mechanisms in parallel (e.g. try to fetch the BIP70 payment\n\u003e\u003e request via\n\u003e\u003e both HTTP and Bluetooth) and go with whatever completes first. But\n\u003e\u003e that is of\n\u003e\u003e course up to each wallet to decide how to handle.\n\u003e\u003e\n\u003e\u003e TBIP75 furthermore proposes to include an additional 'h' parameter\n\u003e\u003e which would\n\u003e\u003e be a hash of the BIP70 payment request, preventing a MITM attack on the\n\u003e\u003e Bluetooth channel even if the BIP70 payment request isn't signed. This\n\u003e\u003e would\n\u003e\u003e have also been my suggestion, although I know that Mike Hearn has raised\n\u003e\u003e concerns about this approach. One being, that one needs to finalize\n\u003e\u003e the BIP70\n\u003e\u003e payment request at the time the QR code and NFC URI is generated.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ## Questions ##\n\u003e\u003e\n\u003e\u003e My questions to the list:\n\u003e\u003e\n\u003e\u003e 1) Do you prefer changing 'optional string payment_url' into 'repeated\n\u003e\u003e string\n\u003e\u003e payment_url' or would you rather introduce a new field\n\u003e\u003e 'additional_payment_urls'?\n\u003e\u003e\n\u003e\u003e 2) @Andreas: Is the r, r1, r2 mechanism already implemented in Bitcoin\n\u003e\u003e Wallet?\n\u003e\u003e\n\u003e\u003e 3) Are there other comments regarding 'h' parameter as per TBIP75?\n\u003e\u003e\n\u003e\u003e 4) General comments, advice, feedback?\n\u003e\u003e\n\u003e\u003e I appreciate your input! :-)\n\u003e\u003e\n\u003e\u003e Cheers,\n\u003e\u003e Jan\n\u003e\u003e\n\u003e\u003e [1] http://andyschroder.com/BitcoinFluidDispenser/\n\u003e\u003e [2]\n\u003e\u003e https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg06354.html\n\u003e\u003e\n\u003e\u003e [3] https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawiki\n\u003e\u003e [4] https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e\n\u003e\u003e Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server\n\u003e\u003e from Actuate! Instantly Supercharge Your Business Reports and Dashboards\n\u003e\u003e with Interactivity, Sharing, Native Excel Exports, App Integration \u0026 more\n\u003e\u003e Get technology previously reserved for billion-dollar corporations, FREE\n\u003e\u003e http://pubads.g.doubleclick.net/gampad/clk?id=190641631\u0026iu=/4140/ostg.clktrk\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e \n\u003e \n\u003e \n\u003e ------------------------------------------------------------------------------\n\u003e Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server\n\u003e from Actuate! Instantly Supercharge Your Business Reports and Dashboards\n\u003e with Interactivity, Sharing, Native Excel Exports, App Integration \u0026 more\n\u003e Get technology previously reserved for billion-dollar corporations, FREE\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=190641631\u0026iu=/4140/ostg.clktrk\n\u003e \n\u003e \n\u003e \n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e \n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 473 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150222/a3e8cdc2/attachment.sig\u003e"}