{"type":"rich","version":"1.0","author_name":"npub1r375vdaydp5nnnytff6ee2kwzxak8whmwkmnkm6h67agr7dadfkqxn6ccq","author_url":"https://nostr.ae/npub1r375vdaydp5nnnytff6ee2kwzxak8whmwkmnkm6h67agr7dadfkqxn6ccq","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-02-22\n📝 Original message:Hello Jan,\n\nRegarding a few of your questions:\n\nAndreas and I had a number of private discussions regarding the \npayment_url parameter. I had suggested a \"additional_payment_urls\" \nrepeated parameter, but he didn't seem to like that idea and I \npersonally am indifferent, so that is why we decided to just change \npayment_url to a repeated field. The spec is simpler without the \n\"additional_payment_urls\", but the wallets have to be a little bit \nsmarter finding the right url they want to use in the list. It's maybe \nnot a bad idea for the wallet to try all payment_url mechanisms in \nparallel. Should we add this as a recommendation to wallets in TBIP75?\n\nI had heard from Andreas a few weeks ago that the multiple r parameters \nwas not yet implemented. Maybe your interest can motivate him to do so!\n\nI actually also happen to be using nfcpy. I am having some reliability \nissues as well with it. What exactly are your problems?\n\nI have seen your video before. I guess I'm wondering how your prototype \nworks with bitpay and bluetooth. Doesn't bitpay sign the payment request \nfor you with an https based payment_url? If so, how do you add the \nbluetooth payment_url while keeping their signature valid? In your video \nit looks like the phone still has cellular and wifi reception (it is not \noffline).\n\nYou mention workflow options 1,2,3. You forgot to mention that options \n1,2 are not backwards compatible with older wallets.\n\nRegarding the NFC data formats. I would like to clarify that the wallets \nare having those events dispatched by the android OS. The \"URI\" and \n\"mime type\" events are sent to the application in the same way as from \nother sources such as a web browser, e-mail, stand alone QR code scanner \napp, etc.. So, I don't think the wallet actually knows it is receiving \nthe event from NFC. That is one reason why so many existing wallets \nhappen to support BIP21 payment request via NFC. Andreas can correct me \nif I am wrong on these statements. I'm a little weary sending the \"mime \ntype\" based format over NFC because of backwards compatibility and \nbecause of the long certificate chain that needs to be transferred. You \nwant that tap to be as robust and fast as possible. A bluetooth \nconnection can have a retry without any user interaction.\n\nI don't really understand why Mike Hearn has the objections to the h \nparameter. It seems like you should already be ready to produce the \nBIP70 payment request at the time when the URI is generated. I'd also \nlike to clarify that the h parameter is for more than just unsigned \npayment requests. You can have a signed payment request with the wrong \nsigner. There is way to much brainpower required to verify that the \nsigner is actually the merchant you are doing business with. Just think \nhow many times you shop at a store that you don't even know the name of. \nAlso, the store may contract their payment processing out to another \nparty, or they may have multiple store names but use the same payment \nprocessing system for all their stores, and the parent company has a \ndifferent name. It's good to have both the h parameter AND the signed \npayment request.\n\nI don't really like the Airbitz proposal. Figuring out if your selecting \nis the right one is a real nuisance. The idea is neat in a few \napplications, but I just don't think it is going to work for people as \nthe most efficient and trouble free option day to day. I realize they \nare probably doing it to work with Apple's limited functionality phones \n(and BLE is a new buzz word). However, I don't think we should base \nbitcoin around what Apple wants us to do. They've already had their war \non bitcoin. They are going to do whatever they can to protect their NFC \nbased payment system. We need to make their platform the the less \ndesirable one if they are going to play the game that way. If that means \nan Airbitz like proposal is implemented as a fallback, maybe that is \nfine and POS systems need to support both, but I just don't think we \nshould limit what we can do because of Apple's products capabilities.\n\nThere is also the \"ack\" memo that I mentioned in reference [2]. I think \nwe can improve upon this really. Can we make a new status field or \ndifferent bluetooth message header? I know Andreas didn't want to change \nit because that is how his app already works, but I don't think the way \nit is is ideal.\n\nI'd like to see some discussion too about securing the bluetooth \nconnection. Right now it is possible for an eavesdropper to monitor the \ndata transferred. I'd personally like to see if wrapping the current \nconnection with SSL works or if we can run https over a bluetooth \nsocket. There was some criticism of this, but I don't think it has been \ntested to know if it is really a problem or not. If we just run https \nover bluetooth, then a lot of my concerns about the message header \ninconsistencies will go away and the connection will also be secure. We \ndon't have to reinvent anything.\n\n\n\nAndy Schroder\n\nOn 02/22/2015 02:08 PM, Jan Vornberger wrote:\n\u003e Hi everyone,\n\u003e\n\u003e I am working on a Bitcoin point of sale terminal based on a Raspberry Pi, which\n\u003e displays QR codes, but also provides payment requests via NFC. It can optionally\n\u003e receive the sender's transaction via Bluetooth, so if the sender wallet\n\u003e supports it, the sender can be completely offline. Only the terminal needs an\n\u003e internet connection.\n\u003e\n\u003e Typical scenario envisioned: Customer taps their smartphone (or maybe smartwatch\n\u003e in the future) on the NFC pad, confirms the transaction on their phone\n\u003e (or smartwatch) and the transaction completes via Bluetooth and/or the phone's\n\u003e internet connection.\n\u003e\n\u003e You can see a prototype in action here:\n\u003e\n\u003e    https://www.youtube.com/watch?v=P7vKHMoapr8\n\u003e\n\u003e The above demo uses a release version of Schildbach's Bitcoin Wallet, so it\n\u003e works as shown today. However, some parts - especially the Bluetooth stuff - are\n\u003e custom extensions of Schildbach's wallet which are not yet standard.\n\u003e\n\u003e I'm writing this post to document my experience implementing NFC and offline\n\u003e payments and hope to move the discussion forward around standardizing some of\n\u003e this stuff. Andy Schroder's work around his Bitcoin Fluid Dispenser [1,2]\n\u003e follows along the same lines, so his proposed TBIP74 [3] and TBIP75 [4] are\n\u003e relevant here as well.\n\u003e\n\u003e\n\u003e ## NFC vs Bluetooth vs NFC+Bluetooth ##\n\u003e\n\u003e Before I get into the implementation details, a few words for why I decided to\n\u003e go with the combination of NFC and Bluetooth:\n\u003e\n\u003e Doing everything via NFC is an interesting option to keep things simple, but the\n\u003e issue is, that one usually can't maintain the connection while the user confirms\n\u003e the transaction (as they take the device back to press a button or maybe enter a\n\u003e PIN). So there are three options:\n\u003e\n\u003e 1. Do a \"double tap\": User taps, takes the device back, confirms, then taps\n\u003e again to transmit the transaction. (I think Google Wallet does something like\n\u003e this.)\n\u003e\n\u003e 2. Confirm beforehand: User confirms, then taps and everything can happen in one\n\u003e go. The disadvantage is, that you confirm the transaction before you have seen\n\u003e the details. (I believe Google Wallet can also work this way.)\n\u003e\n\u003e 3. Tap the phone, then establish a Bluetooth connection which allows you to do\n\u003e all necessary communication even if the user takes the device back.\n\u003e\n\u003e I feel that option 3 is the nicest UX, so that is what I am focusing on right\n\u003e now, but there are pros and cons to all options. One disadvantage of option 3 in\n\u003e practice is, that many users - in my experience - have Bluetooth turned off, so\n\u003e it can result in additional UI dialogs popping up, asking the user to turn on\n\u003e Bluetooth.\n\u003e\n\u003e Regarding doing everything via Bluetooth or maybe BLE: I have been following the\n\u003e work that Airbitz has done around that, but personally I prefer the NFC\n\u003e interaction of \"I touch what I want to pay\" rather than \"a payment request comes\n\u003e to me through the air and I figure out whether it is meant for me/is legitimate\".\n\u003e\n\u003e\n\u003e ## NFC data formats ##\n\u003e\n\u003e A bit of background for those who are not that familiar with NFC: Most Bitcoin\n\u003e wallets with NFC support make use of NDEF (NFC Data Exchange Format) as far as I\n\u003e am aware (with CoinBlesk being an exception, which uses host-based card\n\u003e emulation, if I understand it correctly). NDEF defines a number of record types,\n\u003e among them 'URI' and 'Mime Type'.\n\u003e\n\u003e A common way of using NFC with Bitcoin is to create a URI record that contains a\n\u003e Bitcoin URI. Beyond that Schildbach's wallet (and maybe others?) also support\n\u003e the mime type record, which is then set to 'application/bitcoin-paymentrequest'\n\u003e and the rest of the NFC data is a complete BIP70 payment request.\n\u003e\n\u003e\n\u003e ## Implementation ##\n\u003e\n\u003e To structure the discussion a little bit, I have listed a number of scenarios to\n\u003e consider below. Not every possible combination is listed, but it should cover a\n\u003e bit of everything.\n\u003e\n\u003e Scenarios:\n\u003e\n\u003e 1) Scan QR code, transmit transaction via Bitcoin network\n\u003e     Example QR code: bitcoin:1asdf...?amount=42\n\u003e\n\u003e 2) Touch NFC pad, transmit transaction via Bitcoin network\n\u003e     Example NFC URI: bitcoin:1asdf...?amount=42\n\u003e\n\u003e 3) Scan QR code, fetch BIP70 details via HTTP, post transaction via HTTP\n\u003e     Example QR code: bitcoin:1asdf...?amount=42\u0026r=https://example.org/bip70paymentrequest\n\u003e\n\u003e 4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via HTTP\n\u003e     Example NFC URI: bitcoin:1asdf...?amount=42\u0026r=https://example.org/bip70paymentrequest\n\u003e\n\u003e 5) Touch NFC pad, receive BIP70 details directly, post transaction via HTTP\n\u003e     Example NFC MIME record: application/bitcoin-paymentrequest + BIP70 payment request\n\u003e\n\u003e 6) Scan QR code, fetch BIP70 details via Bluetooth, post transaction via Bluetooth\n\u003e     Example QR code: bitcoin:1asdf...?amount=42\u0026bt=1234567890AB\n\u003e     Payment request has 'payment_url' set to 'bt:1234567890AB'\n\u003e\n\u003e 7) Touch NFC pad, fetch BIP70 details via Bluetooth, post transaction via Bluetooth\n\u003e     Example NFC URI: bitcoin:1asdf...?amount=42\u0026bt=1234567890AB\n\u003e     Payment request has 'payment_url' set to 'bt:1234567890AB'\n\u003e\n\u003e Scenarios 1 and 2 are basically the 'legacy'/pre-BIP70 approach and I am just\n\u003e listing them here for comparison. Scenario 3 is what is often in use now, for\n\u003e example when using a checkout screen by BitPay or Coinbase.\n\u003e\n\u003e I played around with both scenarios 4 and 5, trying to decide whether I should\n\u003e use an NFC URI record or already provide the complete BIP70 payment request via\n\u003e NFC.\n\u003e\n\u003e My experience here has been, that the latter was fairly fragile in my setup\n\u003e (Raspberry Pi, NFC dongle from a company called Sensor ID, using nfcpy). I tried\n\u003e with signed payment requests that were around 4k to 5k and the transfer would\n\u003e often not complete if I didn't hold the phone perfectly in place. So I quickly\n\u003e switched to using the NFC URI record instead and have the phone fetch the BIP70\n\u003e payment request via Bluetooth afterwards. Using this approach the amount of data\n\u003e is small enough that it's usually 'all or nothing' and that seems more robust to\n\u003e me.\n\u003e\n\u003e That said, I continue to have problems with the NFC stack that I'm using, so it\n\u003e might just be my NFC setup that is causing these problems. I will probably give\n\u003e the NXP NFC library a try next (which I believe is also the stack that is used\n\u003e by Android). Maybe I have more luck with that approach and could then switch to\n\u003e scenario 5.\n\u003e\n\u003e Scenarios 6 and 7 is what the terminal is doing right now. The 'bt' parameter is\n\u003e the non-standard extension of Andreas' wallet that I was mentioning. TBIP75\n\u003e proposes to change 'bt' into 'r1' as part of a more generic approach of\n\u003e numbering different sources for the BIP70 payment request. I think that is a\n\u003e good idea and would express my vote for this proposal. So the QR code or NFC URI\n\u003e would then look something like this:\n\u003e\n\u003e    bitcoin:1asdf...?amount=42\u0026r=https://example.org/bip70\u0026r1=bt:1234567890AB/resource\n\u003e\n\u003e In addition the payment request would need to list additional 'payment_url's. My\n\u003e proposal would be to do something like this:\n\u003e\n\u003e      message PaymentDetails {\n\u003e          ...\n\u003e          optional string payment_url = 6;\n\u003e          optional bytes merchant_data = 7;\n\u003e          repeated string additional_payment_urls = 8;\n\u003e            // ^-- new; to hold things like 'bt:1234567890AB'\n\u003e      }\n\u003e\n\u003e TBIP75 proposes to just change 'optional string payment_url' into 'repeated\n\u003e string payment_url'. If this isn't causing any problems (and hopefully not too\n\u003e much confusion?) I guess that would be fine too.\n\u003e\n\u003e In my opinion a wallet should then actually attempt all or multiple of the\n\u003e provided mechanisms in parallel (e.g. try to fetch the BIP70 payment request via\n\u003e both HTTP and Bluetooth) and go with whatever completes first. But that is of\n\u003e course up to each wallet to decide how to handle.\n\u003e\n\u003e TBIP75 furthermore proposes to include an additional 'h' parameter which would\n\u003e be a hash of the BIP70 payment request, preventing a MITM attack on the\n\u003e Bluetooth channel even if the BIP70 payment request isn't signed. This would\n\u003e have also been my suggestion, although I know that Mike Hearn has raised\n\u003e concerns about this approach. One being, that one needs to finalize the BIP70\n\u003e payment request at the time the QR code and NFC URI is generated.\n\u003e\n\u003e\n\u003e ## Questions ##\n\u003e\n\u003e My questions to the list:\n\u003e\n\u003e 1) Do you prefer changing 'optional string payment_url' into 'repeated string\n\u003e payment_url' or would you rather introduce a new field 'additional_payment_urls'?\n\u003e\n\u003e 2) @Andreas: Is the r, r1, r2 mechanism already implemented in Bitcoin Wallet?\n\u003e\n\u003e 3) Are there other comments regarding 'h' parameter as per TBIP75?\n\u003e\n\u003e 4) General comments, advice, feedback?\n\u003e\n\u003e I appreciate your input! :-)\n\u003e\n\u003e Cheers,\n\u003e Jan\n\u003e\n\u003e [1] http://andyschroder.com/BitcoinFluidDispenser/\n\u003e [2] https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg06354.html\n\u003e [3] https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawiki\n\u003e [4] https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki\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 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\u003e\n\u003e\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: 0x2D44186B.asc\nType: application/pgp-keys\nSize: 1739 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150222/230a5e33/attachment.bin\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 555 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150222/230a5e33/attachment.sig\u003e"}