From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YPfag-00040W-6M for bitcoin-development@lists.sourceforge.net; Sun, 22 Feb 2015 23:05:34 +0000 X-ACL-Warn: Received: from mail-pa0-f50.google.com ([209.85.220.50]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YPfae-0006vF-GX for bitcoin-development@lists.sourceforge.net; Sun, 22 Feb 2015 23:05:34 +0000 Received: by pabkx10 with SMTP id kx10so22857464pab.0 for ; Sun, 22 Feb 2015 15:05:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=93xTAKszsu+bWPcGa70zK7qq2Dce2sHiB6WvAnU6kWI=; b=Q1NxTIEA1pm6ObqR/5owA726oTrUyD880Dbsaf9OwOAanTYPRgeNTuYNidcObU3uqb 8voLUJcpvJHewuixSlZPZV4chSZit/NV92IGR39aKO+vUKlLM1Ii/iMvJ6MjFdiG/xjw hf1ly8ml7L3cixTK1XOBs7hyprRmN3qMtRe+xsDrvon7fGM64VJe9M22/tSTRoxpyRBj MM8wZ+jUvTov2YCVbT1ejTLimOHBXrLE4uqARd+k4U5aget0Jc2tk+UOaE/1c6OrTRkd CdhsyPwlDbhZk73xsUkLnqtc0RADpr+CD/ZTs///EHFLavXqmEBKaohrVxOGAPBV5IMT 1Ymg== X-Gm-Message-State: ALoCoQlBOiZ4zv9qBPrIkGfKaKomHAwkA1KfGfT0q1E6FXWPtqb+3OoAwG7jqRU7yNiBQsDlwXuL X-Received: by 10.66.158.200 with SMTP id ww8mr5681698pab.45.1424646326806; Sun, 22 Feb 2015 15:05:26 -0800 (PST) Received: from [10.0.1.3] (c-50-135-46-157.hsd1.wa.comcast.net. [50.135.46.157]) by mx.google.com with ESMTPSA id ce1sm33620011pdb.34.2015.02.22.15.05.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Feb 2015 15:05:26 -0800 (PST) Message-ID: <54EA60D9.8000001@voskuil.org> Date: Sun, 22 Feb 2015 15:06:01 -0800 From: Eric Voskuil User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Andy Schroder , Jan Vornberger , bitcoin-development@lists.sourceforge.net References: <20150222190839.GA18527@odo.localdomain> <54EA5A1C.2020701@AndySchroder.com> In-Reply-To: <54EA5A1C.2020701@AndySchroder.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huf57hgGMfXbAeUuhXbLdA9075numHmUB" X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1YPfae-0006vF-GX Subject: Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 23:05:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --huf57hgGMfXbAeUuhXbLdA9075numHmUB Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 02/22/2015 02:37 PM, Andy Schroder wrote: > I'd like to see some discussion too about securing the bluetooth > connection. Right now it is possible for an eavesdropper to monitor the= > data transferred.=20 Yes, this should be a prerequisite issue to all others. > I'd personally like to see if wrapping the current > connection with SSL works or if we can run https over a bluetooth > socket.=20 There is no reason to add this significant complexity. The purpose of SSL/TLS is to establish privacy over a *public* channel. But to do so requires verification by the user of the merchant's public certificate. Once we rely on the channel being *private*, the entire SSL process is unnecessary. Presumably we would not want to require PKI for privacy, since that's a bit of a contradiction. But if one wants to do this NFC is not required, since the private session can be established over the public (Bluetooth) network. > There was some criticism of this, but I don't think it has been > tested to know if it is really a problem or not. If we just run https > over bluetooth, then a lot of my concerns about the message header > inconsistencies will go away and the connection will also be secure. We= > don't have to reinvent anything. >=20 >=20 >=20 > Andy Schroder >=20 > On 02/22/2015 02:08 PM, Jan Vornberger wrote: >> Hi everyone, >> >> I am working on a Bitcoin point of sale terminal based on a Raspberry >> Pi, which >> displays QR codes, but also provides payment requests via NFC. It can >> optionally >> receive the sender's transaction via Bluetooth, so if the sender walle= t >> supports it, the sender can be completely offline. Only the terminal >> needs an >> internet connection. >> >> Typical scenario envisioned: Customer taps their smartphone (or maybe >> smartwatch >> in the future) on the NFC pad, confirms the transaction on their phone= >> (or smartwatch) and the transaction completes via Bluetooth and/or the= >> phone's >> internet connection. >> >> You can see a prototype in action here: >> >> https://www.youtube.com/watch?v=3DP7vKHMoapr8 >> >> The above demo uses a release version of Schildbach's Bitcoin Wallet, >> so it >> works as shown today. However, some parts - especially the Bluetooth >> stuff - are >> custom extensions of Schildbach's wallet which are not yet standard. >> >> I'm writing this post to document my experience implementing NFC and >> offline >> payments and hope to move the discussion forward around standardizing >> some of >> this stuff. Andy Schroder's work around his Bitcoin Fluid Dispenser [1= ,2] >> follows along the same lines, so his proposed TBIP74 [3] and TBIP75 >> [4] are >> relevant here as well. >> >> >> ## NFC vs Bluetooth vs NFC+Bluetooth ## >> >> Before I get into the implementation details, a few words for why I >> decided to >> go with the combination of NFC and Bluetooth: >> >> Doing everything via NFC is an interesting option to keep things >> simple, but the >> issue is, that one usually can't maintain the connection while the >> user confirms >> the transaction (as they take the device back to press a button or >> maybe enter a >> PIN). So there are three options: >> >> 1. Do a "double tap": User taps, takes the device back, confirms, then= >> taps >> again to transmit the transaction. (I think Google Wallet does >> something like >> this.) >> >> 2. Confirm beforehand: User confirms, then taps and everything can >> happen in one >> go. The disadvantage is, that you confirm the transaction before you >> have seen >> the details. (I believe Google Wallet can also work this way.) >> >> 3. Tap the phone, then establish a Bluetooth connection which allows >> you to do >> all necessary communication even if the user takes the device back. >> >> I feel that option 3 is the nicest UX, so that is what I am focusing >> on right >> now, but there are pros and cons to all options. One disadvantage of >> option 3 in >> practice is, that many users - in my experience - have Bluetooth >> turned off, so >> it can result in additional UI dialogs popping up, asking the user to >> turn on >> Bluetooth. >> >> Regarding doing everything via Bluetooth or maybe BLE: I have been >> following the >> work that Airbitz has done around that, but personally I prefer the NF= C >> interaction of "I touch what I want to pay" rather than "a payment >> request comes >> to me through the air and I figure out whether it is meant for me/is >> legitimate". >> >> >> ## NFC data formats ## >> >> A bit of background for those who are not that familiar with NFC: Most= >> Bitcoin >> wallets with NFC support make use of NDEF (NFC Data Exchange Format) >> as far as I >> am aware (with CoinBlesk being an exception, which uses host-based car= d >> emulation, if I understand it correctly). NDEF defines a number of >> record types, >> among them '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 (and maybe others?) also >> support >> the mime type record, which is then set to >> 'application/bitcoin-paymentrequest' >> and the rest of the NFC data is a complete BIP70 payment request. >> >> >> ## Implementation ## >> >> To structure the discussion a little bit, I have listed a number of >> scenarios to >> consider below. Not every possible combination is listed, but it >> should cover a >> bit of everything. >> >> Scenarios: >> >> 1) Scan QR code, transmit transaction via Bitcoin network >> Example QR code: bitcoin:1asdf...?amount=3D42 >> >> 2) Touch NFC pad, transmit transaction via Bitcoin network >> Example NFC URI: bitcoin:1asdf...?amount=3D42 >> >> 3) Scan QR code, fetch BIP70 details via HTTP, post transaction via HT= TP >> Example QR code: >> bitcoin:1asdf...?amount=3D42&r=3Dhttps://example.org/bip70paymentreque= st >> >> 4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via H= TTP >> Example NFC URI: >> bitcoin:1asdf...?amount=3D42&r=3Dhttps://example.org/bip70paymentreque= st >> >> 5) Touch NFC pad, receive BIP70 details directly, post transaction via= >> HTTP >> Example NFC MIME record: application/bitcoin-paymentrequest + >> BIP70 payment request >> >> 6) Scan QR code, fetch BIP70 details via Bluetooth, post transaction >> via Bluetooth >> Example QR code: bitcoin:1asdf...?amount=3D42&bt=3D1234567890AB >> Payment request has 'payment_url' set to 'bt:1234567890AB' >> >> 7) Touch NFC pad, fetch BIP70 details via Bluetooth, post transaction >> via Bluetooth >> Example NFC URI: bitcoin:1asdf...?amount=3D42&bt=3D1234567890AB >> Payment request has 'payment_url' set to 'bt:1234567890AB' >> >> Scenarios 1 and 2 are basically the 'legacy'/pre-BIP70 approach and I >> am just >> listing them here for comparison. Scenario 3 is what is often in use >> now, for >> example when using a checkout screen by BitPay or Coinbase. >> >> I played around with both scenarios 4 and 5, trying to decide whether >> I should >> use an NFC URI record or already provide the complete BIP70 payment >> request via >> NFC. >> >> My experience here has been, that the latter was fairly fragile in my >> setup >> (Raspberry Pi, NFC dongle from a company called Sensor ID, using >> nfcpy). I tried >> with signed payment requests that were around 4k to 5k and the >> transfer would >> often not complete if I didn't hold the phone perfectly in place. So I= >> quickly >> switched to using the NFC URI record instead and have the phone fetch >> the BIP70 >> payment request via Bluetooth afterwards. Using this approach the >> amount of data >> is small enough that it's usually 'all or nothing' and that seems more= >> robust to >> me. >> >> That said, I continue to have problems with the NFC stack that I'm >> using, so it >> might just be my NFC setup that is causing these problems. I will >> probably give >> the NXP NFC library a try next (which I believe is also the stack that= >> is used >> by Android). Maybe I have more luck with that approach and could then >> switch to >> scenario 5. >> >> Scenarios 6 and 7 is what the terminal is doing right now. The 'bt' >> parameter is >> the non-standard extension of Andreas' wallet that I was mentioning. >> TBIP75 >> proposes to change 'bt' into 'r1' as part of a more generic approach o= f >> numbering different sources for the BIP70 payment request. I think >> that is a >> good idea and would express my vote for this proposal. So the QR code >> or NFC URI >> would then look something like this: >> >> =20 >> bitcoin:1asdf...?amount=3D42&r=3Dhttps://example.org/bip70&r1=3Dbt:123= 4567890AB/resource >> >> >> In addition the payment request would need to list additional >> 'payment_url's. My >> proposal would be to do something like this: >> >> message PaymentDetails { >> ... >> optional string payment_url =3D 6; >> optional bytes merchant_data =3D 7; >> repeated string additional_payment_urls =3D 8; >> // ^-- new; to hold things like 'bt:1234567890AB' >> } >> >> TBIP75 proposes to just change 'optional string payment_url' into >> 'repeated >> string payment_url'. If this isn't causing any problems (and hopefully= >> not too >> much confusion?) I guess that would be fine too. >> >> In my opinion a wallet should then actually attempt all or multiple of= >> the >> provided mechanisms in parallel (e.g. try to fetch the BIP70 payment >> request via >> both HTTP and Bluetooth) and go with whatever completes first. But >> that is of >> course up to each wallet to decide how to handle. >> >> TBIP75 furthermore proposes to include an additional 'h' parameter >> which would >> be a hash of the BIP70 payment request, preventing a MITM attack on th= e >> Bluetooth channel even if the BIP70 payment request isn't signed. This= >> would >> have also been my suggestion, although I know that Mike Hearn has rais= ed >> concerns about this approach. One being, that one needs to finalize >> the BIP70 >> payment request at the time the QR code and NFC URI is generated. >> >> >> ## Questions ## >> >> My questions to the list: >> >> 1) Do you prefer changing 'optional string payment_url' into 'repeated= >> string >> payment_url' or would you rather introduce a new field >> 'additional_payment_urls'? >> >> 2) @Andreas: Is the r, r1, r2 mechanism already implemented in Bitcoin= >> Wallet? >> >> 3) Are there other comments regarding 'h' parameter as per TBIP75? >> >> 4) General comments, advice, feedback? >> >> I appreciate your input! :-) >> >> Cheers, >> Jan >> >> [1] http://andyschroder.com/BitcoinFluidDispenser/ >> [2] >> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.n= et/msg06354.html >> >> [3] https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawi= ki >> [4] https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawi= ki >> >> ----------------------------------------------------------------------= -------- >> >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >> from Actuate! Instantly Supercharge Your Business Reports and Dashboar= ds >> with Interactivity, Sharing, Native Excel Exports, App Integration & m= ore >> Get technology previously reserved for billion-dollar corporations, FR= EE >> http://pubads.g.doubleclick.net/gampad/clk?id=3D190641631&iu=3D/4140/o= stg.clktrk >> >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> >> >=20 >=20 >=20 > -----------------------------------------------------------------------= ------- > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboard= s > with Interactivity, Sharing, Native Excel Exports, App Integration & mo= re > Get technology previously reserved for billion-dollar corporations, FRE= E > http://pubads.g.doubleclick.net/gampad/clk?id=3D190641631&iu=3D/4140/os= tg.clktrk >=20 >=20 >=20 > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >=20 --huf57hgGMfXbAeUuhXbLdA9075numHmUB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU6mDZAAoJEDzYwH8LXOFONjcH/imlqBpxzZoZc+fs5qX91bnX RzoyFbibT320UJMC1IrvEglb44asFbmnQnB6pv+8IUVCtd7nrwqHuFIGhRjLA3uj vGXaKf0nzqy8TTRw1bxEftdZ5uV4JBMj2oNjzw6uWRPaKtYn3xfmmv5c8RCkrdvW GmXtj94oJCZ/Xxhgj23ydcGaa7Tu6ba7VyM98Y7oUPr5rllIpS3r7q8pxyQ0SzOi 2RAHqy8pc9PBhLiNjax34buyPzOD/jR6uN4GpXlieMWB8E5/pudTVBDfJMtxlAZg 4CeEU2SX2maNbwdnvXxAgzjuSWk3LzjdUHzSkLvMZJL7khMNUq05bA4Mr079x+M= =zB1B -----END PGP SIGNATURE----- --huf57hgGMfXbAeUuhXbLdA9075numHmUB--