Message-ID: <54EA5A1C.2020701@AndySchroder.com>
Date: Sun, 22 Feb 2015 17:37:16 -0500
From: Andy Schroder <info@AndySchroder.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Jan Vornberger <jan@uos.de>, 
 bitcoin-development@lists.sourceforge.net
References: <20150222190839.GA18527@odo.localdomain>
In-Reply-To: <20150222190839.GA18527@odo.localdomain>
OpenPGP: id=2D44186B;
	url=http://andyschroder.com/static/AndySchroder.asc
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="mx6K8SRVsli4JsJREQm3uwIku04a76UtJ"
Subject: Re: [Bitcoin-development] Bitcoin at POS using BIP70,
 NFC and offline payments - implementer feedback
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--mx6K8SRVsli4JsJREQm3uwIku04a76UtJ
Content-Type: multipart/mixed; boundary="------------070100040705060602090000"

This is a multi-part message in MIME format.
--------------070100040705060602090000
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hello Jan,

Regarding a few of your questions:

Andreas and I had a number of private discussions regarding the=20
payment_url parameter. I had suggested a "additional_payment_urls"=20
repeated parameter, but he didn't seem to like that idea and I=20
personally am indifferent, so that is why we decided to just change=20
payment_url to a repeated field. The spec is simpler without the=20
"additional_payment_urls", but the wallets have to be a little bit=20
smarter finding the right url they want to use in the list. It's maybe=20
not a bad idea for the wallet to try all payment_url mechanisms in=20
parallel. Should we add this as a recommendation to wallets in TBIP75?

I had heard from Andreas a few weeks ago that the multiple r parameters=20
was not yet implemented. Maybe your interest can motivate him to do so!

I actually also happen to be using nfcpy. I am having some reliability=20
issues as well with it. What exactly are your problems?

I have seen your video before. I guess I'm wondering how your prototype=20
works with bitpay and bluetooth. Doesn't bitpay sign the payment request =

for you with an https based payment_url? If so, how do you add the=20
bluetooth payment_url while keeping their signature valid? In your video =

it looks like the phone still has cellular and wifi reception (it is not =

offline).

You mention workflow options 1,2,3. You forgot to mention that options=20
1,2 are not backwards compatible with older wallets.

Regarding the NFC data formats. I would like to clarify that the wallets =

are having those events dispatched by the android OS. The "URI" and=20
"mime type" events are sent to the application in the same way as from=20
other sources such as a web browser, e-mail, stand alone QR code scanner =

app, etc.. So, I don't think the wallet actually knows it is receiving=20
the event from NFC. That is one reason why so many existing wallets=20
happen to support BIP21 payment request via NFC. Andreas can correct me=20
if I am wrong on these statements. I'm a little weary sending the "mime=20
type" based format over NFC because of backwards compatibility and=20
because of the long certificate chain that needs to be transferred. You=20
want that tap to be as robust and fast as possible. A bluetooth=20
connection can have a retry without any user interaction.

I don't really understand why Mike Hearn has the objections to the h=20
parameter. It seems like you should already be ready to produce the=20
BIP70 payment request at the time when the URI is generated. I'd also=20
like to clarify that the h parameter is for more than just unsigned=20
payment requests. You can have a signed payment request with the wrong=20
signer. There is way to much brainpower required to verify that the=20
signer is actually the merchant you are doing business with. Just think=20
how many times you shop at a store that you don't even know the name of. =

Also, the store may contract their payment processing out to another=20
party, or they may have multiple store names but use the same payment=20
processing system for all their stores, and the parent company has a=20
different name. It's good to have both the h parameter AND the signed=20
payment request.

I don't really like the Airbitz proposal. Figuring out if your selecting =

is the right one is a real nuisance. The idea is neat in a few=20
applications, but I just don't think it is going to work for people as=20
the most efficient and trouble free option day to day. I realize they=20
are probably doing it to work with Apple's limited functionality phones=20
(and BLE is a new buzz word). However, I don't think we should base=20
bitcoin around what Apple wants us to do. They've already had their war=20
on bitcoin. They are going to do whatever they can to protect their NFC=20
based payment system. We need to make their platform the the less=20
desirable one if they are going to play the game that way. If that means =

an Airbitz like proposal is implemented as a fallback, maybe that is=20
fine and POS systems need to support both, but I just don't think we=20
should limit what we can do because of Apple's products capabilities.

There is also the "ack" memo that I mentioned in reference [2]. I think=20
we can improve upon this really. Can we make a new status field or=20
different bluetooth message header? I know Andreas didn't want to change =

it because that is how his app already works, but I don't think the way=20
it is is ideal.

I'd like to see some discussion too about securing the bluetooth=20
connection. Right now it is possible for an eavesdropper to monitor the=20
data transferred. I'd personally like to see if wrapping the current=20
connection with SSL works or if we can run https over a bluetooth=20
socket. There was some criticism of this, but I don't think it has been=20
tested to know if it is really a problem or not. If we just run https=20
over bluetooth, then a lot of my concerns about the message header=20
inconsistencies will go away and the connection will also be secure. We=20
don't have to reinvent anything.



Andy Schroder

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 P=
i, which
> displays QR codes, but also provides payment requests via NFC. It can o=
ptionally
> receive the sender's transaction via Bluetooth, so if the sender wallet=

> supports it, the sender can be completely offline. Only the terminal ne=
eds an
> internet connection.
>
> Typical scenario envisioned: Customer taps their smartphone (or maybe s=
martwatch
> 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, s=
o it
> works as shown today. However, some parts - especially the Bluetooth st=
uff - are
> custom extensions of Schildbach's wallet which are not yet standard.
>
> I'm writing this post to document my experience implementing NFC and of=
fline
> payments and hope to move the discussion forward around standardizing s=
ome 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 dec=
ided 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 mayb=
e 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 somethin=
g like
> this.)
>
> 2. Confirm beforehand: User confirms, then taps and everything can happ=
en in one
> go. The disadvantage is, that you confirm the transaction before you ha=
ve seen
> the details. (I believe Google Wallet can also work this way.)
>
> 3. Tap the phone, then establish a Bluetooth connection which allows yo=
u 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 op=
tion 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 t=
urn on
> Bluetooth.
>
> Regarding doing everything via Bluetooth or maybe BLE: I have been foll=
owing the
> work that Airbitz has done around that, but personally I prefer the NFC=

> interaction of "I touch what I want to pay" rather than "a payment requ=
est comes
> to me through the air and I figure out whether it is meant for me/is le=
gitimate".
>
>
> ## 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 card=

> emulation, if I understand it correctly). NDEF defines a number of reco=
rd types,
> among them 'URI' and 'Mime Type'.
>
> A common way of using NFC with Bitcoin is to create a URI record that c=
ontains a
> Bitcoin URI. Beyond that Schildbach's wallet (and maybe others?) also s=
upport
> the mime type record, which is then set to 'application/bitcoin-payment=
request'
> 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 sce=
narios 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 HTT=
P
>     Example QR code: bitcoin:1asdf...?amount=3D42&r=3Dhttps://example.o=
rg/bip70paymentrequest
>
> 4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via HT=
TP
>     Example NFC URI: bitcoin:1asdf...?amount=3D42&r=3Dhttps://example.o=
rg/bip70paymentrequest
>
> 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 vi=
a 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 v=
ia 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 a=
m just
> listing them here for comparison. Scenario 3 is what is often in use no=
w, 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 req=
uest via
> NFC.
>
> My experience here has been, that the latter was fairly fragile in my s=
etup
> (Raspberry Pi, NFC dongle from a company called Sensor ID, using nfcpy)=
=2E 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 t=
he BIP70
> payment request via Bluetooth afterwards. Using this approach the amoun=
t 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 usin=
g, so it
> might just be my NFC setup that is causing these problems. I will proba=
bly 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 s=
witch to
> scenario 5.
>
> Scenarios 6 and 7 is what the terminal is doing right now. The 'bt' par=
ameter is
> the non-standard extension of Andreas' wallet that I was mentioning. TB=
IP75
> proposes to change 'bt' into 'r1' as part of a more generic approach of=

> 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 o=
r NFC URI
> would then look something like this:
>
>    bitcoin:1asdf...?amount=3D42&r=3Dhttps://example.org/bip70&r1=3Dbt:1=
234567890AB/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 'repe=
ated
> 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 re=
quest 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 whic=
h 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. This =
would
> have also been my suggestion, although I know that Mike Hearn has raise=
d
> 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_paym=
ent_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.sourceforg=
e.net/msg06354.html
> [3] https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawik=
i
> [4] https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawik=
i
>
> -----------------------------------------------------------------------=
-------
> 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
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>


--------------070100040705060602090000
Content-Type: application/pgp-keys;
 name="0x2D44186B.asc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0x2D44186B.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.12 (GNU/Linux)

mQENBFD3HqABCADXMSjjwfBroE7n98HE5BSqqlSSnzzlntr09o3c1wzNhAbUe+fg
wOYSLgoPIbjFmtXZAhTVhN6DftNeepl8Rg7SSDeK3F7CeZObVKf5LJQI438stzzK
GctPZ31m6XFqCktPV59pbGRt5M6x1RX38sheAJNrLv7aDDchO4bS/yRkiNzOUPxw
2sINDz5kloRCFKace9oxL8RK25zXickJdprRfbuyKPFve11RsH5btHmV+D/KDD1y
iUapbkGEkCNrecdRyG144863RQ4O1GHb3j/HAxDtq1Lz9BFIaZxWQG1nBAXVD/x/
YmZvyXUD2j4WryHGCK7LLCxq/8irJ/1aDcMFABEBAAG0JUFuZHkgU2Nocm9kZXIg
PGluZm9AQW5keVNjaHJvZGVyLmNvbT6JAT4EEwECACgFAlD3HqACGwMFCQlmAYAG
CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEDT679stRBhrezcIAL/2B44bfTdb
0iELHmuqdPYGJQo1jC3LQzUelIQFMkWYJfh8oRmKeN8QcdWnuGGYdXFMS/zXcZwq
ERQ+nsnf1xnuyXbBK3I6/LdLHjZ8vYgB1erlGmB4quRuU/vYjCO57cfMDeypq5yZ
Ww8h3iHkgj2y9CwOCq8jeOtgJf28beDnv2c2GKzP6I/WccAzpppNkkccBZNb7H7S
Rc88o/Na5kc7Vd2nGK0xIiLU17ui0ylZP59f+wkGAl00pVwiBgLth1knjf9tXRNq
tzITyPO19PHIs1Nwv7EPl/T5YMBCcOCrPjB1nCamowJXbxiwpEQOtoBEH+NMr8ZP
l6dWLnmQs4G5AQ0EUPceoAEIALSJqTfAJcTJA23kLsRmTpWSKaMxv58wj2F9GrEH
7G0Jl14sNJqVVInfB6pfzK2+vRt3Eq2qN0Mg2uS2StLgsLU7B7PyluMj3ALnyvcQ
NfzKNM6rdESxuCc/Faq9fVTMc95P4199hwx4DMKTSL2b9awtz1oHlOr/x/AWt1UL
j/i6kmI1pDGqdSmbTVg4hV6vH1PRXVhECKw5uADOzMINomp/6Pyb6AgJuLSQBKmq
rhwC8M2vDM+K5uFXr1tIeymLfn+sbM/xwtTMXa/br9qw1FF40vv58qKR+mw7upMx
L9Q+hDvGrfhXGTfxTzoRBAUwbBDjVp5sd0FQihixXA8RQPsAEQEAAYkBJQQYAQIA
DwUCUPceoAIbDAUJCWYBgAAKCRA0+u/bLUQYa0KrB/45Czrrb8vVq5sQTnl9lbE6
gmP0nMH0pyLLZr6NemqBC6WVh/IBkh8AUmXVLgJs70W2zQavemMGA58KifJYDu9y
oRDinyNcc9jBOoVh0iqzVH2IyY3aBr6CFGA5P9vo191apCPgz1hUXRqhK3bHiHbz
rPICNQeH+LI7Ds69AYl9Ql1gG2Q2Ewpw+xs6JPVt2RfHCPhe/5N1zt5BTftOp2ed
Oa8IYWtIRJkeXv/5sSYvVB5ZlmJvIjww/qc8MD/0ZiBKZ5tsadQsMKH/7o7uu+Ub
1QHk3x6QFGLo8B+sQQMgqHemJ/igSAuzQ2guAyRQSYu4TB9XtacAJSpuIAOtva/e
=3DT0y4
-----END PGP PUBLIC KEY BLOCK-----

--------------070100040705060602090000--

--mx6K8SRVsli4JsJREQm3uwIku04a76UtJ
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.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJU6locAAoJEDT679stRBhrjEIH/3a2lAtEeLyzNABRvmQ8MpU6
moxjrsNFkNr1kCM/ki2ZkkqWq7zbUQiWZM3CzdwE/w4tLpOxluggKI0m3pG9MfMf
yQXAyoeL7DKBmVLBNvvbsPJV4nQZbdc7yM3sh5PuYJeGx9x5M5WTUVTYsBU91Y8X
Q7PE9Vf05aWC8SRz0nrOVIaidoy7BXQe+7Y/lULeq2Z+zCZs/8qQx/RzQM39z8Fy
DgH0+hJlorDYm34f6dhcSxUIRf7c3h8rDWN8SbUqDNWfazP/QkWUD/nJjnAQeSAF
bBvY5OJtQqAGD5FgwdXNUu/31LXuI25BWlGsfDHnKnKW0dJnSuo7z496BP2+OW8=
=7ZUA
-----END PGP SIGNATURE-----

--mx6K8SRVsli4JsJREQm3uwIku04a76UtJ--