Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YPg3S-0003GB-Lz for bitcoin-development@lists.sourceforge.net; Sun, 22 Feb 2015 23:35:18 +0000 X-ACL-Warn: Received: from uschroder.com ([74.142.93.202]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1YPg3P-0002hr-Rk for bitcoin-development@lists.sourceforge.net; Sun, 22 Feb 2015 23:35:18 +0000 Received: from [192.168.253.4] (cpe-74-137-24-201.swo.res.rr.com [74.137.24.201]) by uschroder.com (Postfix) with ESMTPSA id AA31A22BD6981; Sun, 22 Feb 2015 18:35:09 -0500 (EST) Message-ID: <54EA67AB.6040002@AndySchroder.com> Date: Sun, 22 Feb 2015 18:35:07 -0500 From: Andy Schroder User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Eric Voskuil , Jan Vornberger , bitcoin-development@lists.sourceforge.net References: <20150222190839.GA18527@odo.localdomain> <54EA5AAE.3040306@voskuil.org> <54EA5CB4.5030302@voskuil.org> In-Reply-To: <54EA5CB4.5030302@voskuil.org> X-Enigmail-Version: 1.6 OpenPGP: id=2D44186B; url=http://andyschroder.com/static/AndySchroder.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Vlthew3OPu94VSLtQ2nOQHjjiePehW1wt" X-Spam-Score: 0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message -0.5 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YPg3P-0002hr-Rk 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:35:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Vlthew3OPu94VSLtQ2nOQHjjiePehW1wt Content-Type: multipart/alternative; boundary="------------050805020100070201090000" This is a multi-part message in MIME format. --------------050805020100070201090000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Andy Schroder On 02/22/2015 05:48 PM, Eric Voskuil wrote: > One correction inline below. > > e > > On 02/22/2015 02:39 PM, Eric Voskuil wrote: >> Hi Jan, >> >> This is really nice work. >> >> WRT the Schroder and Schildbach proposal, the generalization of the "r= " >> and "payment_url" parameters makes sense, with only the potential >> backward compat issue on payment_url. >> >>> TBIP75 furthermore proposes to include 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. This would have also been my suggestion, although I >>> know that Mike Hearn has raised 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. >>> ... >>> 3) Are there other comments regarding 'h' parameter as per TBIP75? >> Yes, this design is problematic from a privacy standpoint. Anyone with= in >> the rather significant range of the Bluetooth terminal is able to >> capture payment requests and correlate them to people. In other words = it >> can be used to automate tainting. >> >> The problem is easily resolved by recognizing that, in the envisioned >> face-to-face trade, proximity is the source of trust. Even in the abov= e >> proposal the "h" parameter is trusted because it was obtained by >> proximity to the NFC terminal. The presumption is that this proximity >> produces a private channel. >> >> As such the "tap" should transfer a session key used for symmetric blo= ck >> cipher over the Bluetooth channel. This also resolves the issue of >> needing to formulate the payment request before the NFC. >> >> As an aside, in other scenarios, such as an automated dispenser, this >> presumption does not hold. The merchant is not present to guard agains= t >> device tampering. Those scenarios can be secured using BIP70, but cann= ot >> guarantee privacy. >> >> The other differences I have with the proposal pertain to efficiency, >> not privacy or integrity of the transaction: >> >> The proposed resource name is redundant with any unique identifier for= >> the session. For example, the "h" parameter is sufficient. But with th= e >> establishment of a session key both as I propose above, the parties ca= n >> derive a sufficiently unique public resource name from a hash of the >> key. An additional advantage is that the resource name can be >> fixed-length, simplifying the encoding/decoding. >> >> The MAC address (and resource name) should be encoded using base58. Th= is > The MAC address (and session key) should be encoded using base58. This As I mentioned in my other e-mail, I don't know that we can consider=20 this NFC a private channel, so I don't think a session key should be=20 transmitted over it. > >> is shorter than base16, is often shorter than base64, better >> standardized and does not require URI encoding, and is generally >> available to implementers. >> >> There is no need for the establishment of two Bluetooth services. >> >> I would change the payment_url recommendation so that the list order >> represents a recommended ordering provided by the terminal for the wal= let. >> >> I wrote up my thoughts on these considerations last year and recently >> revised it by adding a section at the end to incorporate the "r" and >> "payment_url" generalizations from Andreas and Andy. The order is set so that it maintains backwards compatibility by=20 providing the https request first. As mentioned in the proposal, the=20 order of the r parameters has the recommended (but not required)=20 priority. The wallet is encouraged to use the same protocol (but not=20 required). >> >> https://github.com/evoskuil/bips/tree/master/docs >> >> e >> >> >> On 02/22/2015 11:08 AM, 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 wall= et >>> 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 phon= e >>> (or smartwatch) and the transaction completes via Bluetooth and/or th= e 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 d= ecided to >>> go with the combination of NFC and Bluetooth: >>> >>> Doing everything via NFC is an interesting option to keep things simp= le, but the >>> issue is, that one usually can't maintain the connection while the us= er confirms >>> the transaction (as they take the device back to press a button or ma= ybe enter a >>> PIN). So there are three options: >>> >>> 1. Do a "double tap": User taps, takes the device back, confirms, the= n taps >>> again to transmit the transaction. (I think Google Wallet does someth= ing like >>> this.) >>> >>> 2. Confirm beforehand: User confirms, then taps and everything can ha= ppen 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 turn= ed 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 fo= llowing the >>> work that Airbitz has done around that, but personally I prefer the N= FC >>> interaction of "I touch what I want to pay" rather than "a payment re= quest 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: Mos= t 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 ca= rd >>> emulation, if I understand it correctly). NDEF defines a number of re= cord 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-payme= ntrequest' >>> 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 s= cenarios to >>> consider below. Not every possible combination is listed, but it shou= ld 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 H= TTP >>> Example QR code: bitcoin:1asdf...?amount=3D42&r=3Dhttps://example= =2Eorg/bip70paymentrequest >>> >>> 4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via = HTTP >>> Example NFC URI: bitcoin:1asdf...?amount=3D42&r=3Dhttps://example= =2Eorg/bip70paymentrequest >>> >>> 5) Touch NFC pad, receive BIP70 details directly, post transaction vi= a HTTP >>> Example NFC MIME record: application/bitcoin-paymentrequest + BIP= 70 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 r= equest 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 nfcp= y). I tried >>> with signed payment requests that were around 4k to 5k and the transf= er 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 amo= unt of data >>> is small enough that it's usually 'all or nothing' and that seems mor= e robust to >>> me. >>> >>> That said, I continue to have problems with the NFC stack that I'm us= ing, so it >>> might just be my NFC setup that is causing these problems. I will pro= bably give >>> the NXP NFC library a try next (which I believe is also the stack tha= t 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' p= arameter 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 = of >>> numbering different sources for the BIP70 payment request. I think th= at 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: >>> >>> bitcoin:1asdf...?amount=3D42&r=3Dhttps://example.org/bip70&r1=3Dbt= :1234567890AB/resource >>> >>> In addition the payment request would need to list additional 'paymen= t_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 're= peated >>> string payment_url'. If this isn't causing any problems (and hopefull= y not too >>> much confusion?) I guess that would be fine too. >>> >>> In my opinion a wallet should then actually attempt all or multiple o= f 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 th= at is of >>> course up to each wallet to decide how to handle. >>> >>> TBIP75 furthermore proposes to include an additional 'h' parameter wh= ich would >>> be a hash of the BIP70 payment request, preventing a MITM attack on t= he >>> Bluetooth channel even if the BIP70 payment request isn't signed. Thi= s would >>> have also been my suggestion, although I know that Mike Hearn has rai= sed >>> concerns about this approach. One being, that one needs to finalize t= he 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 'repeate= d string >>> payment_url' or would you rather introduce a new field 'additional_pa= yment_urls'? >>> >>> 2) @Andreas: Is the r, r1, r2 mechanism already implemented in Bitcoi= n 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.sourcefo= rge.net/msg06354.html >>> [3] https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediaw= iki >>> [4] https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediaw= iki >>> >>> ---------------------------------------------------------------------= --------- >>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >>> from Actuate! Instantly Supercharge Your Business Reports and Dashboa= rds >>> with Interactivity, Sharing, Native Excel Exports, App Integration & = more >>> Get technology previously reserved for billion-dollar corporations, F= REE >>> http://pubads.g.doubleclick.net/gampad/clk?id=3D190641631&iu=3D/4140/= ostg.clktrk >>> _______________________________________________ >>> Bitcoin-development mailing list >>> Bitcoin-development@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >>> > > > -----------------------------------------------------------------------= ------- > 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 --------------050805020100070201090000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 

Andy Schroder
On 02/22/2015 05:48 PM, Eric Voskuil wrote:
One correction inline below.

e

On 02/22/2015 02:39 PM, Eric Voskuil wrote:

Hi Jan,

This is really nice work.

WRT the Schroder and Schildbach proposal, the generalization of the "r"
and "payment_url" parameters makes sense, with only the potential
backward compat issue on payment_url.


TBIP75 furthermore proposes to include an additi=
onal '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. This would have also been my suggestion, although I
know that Mike Hearn has raised 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.
=2E..
3) Are there other comments regarding 'h' parameter as per TBIP75?

Yes, this design is problematic from a privacy standpoint. Anyone within
the rather significant range of the Bluetooth terminal is able to
capture payment requests and correlate them to people. In other words it
can be used to automate tainting.

The problem is easily resolved by recognizing that, in the envisioned
face-to-face trade, proximity is the source of trust. Even in the above
proposal the "h" parameter is trusted because it was obtained by
proximity to the NFC terminal. The presumption is that this proximity
produces a private channel.

As such the "tap" should transfer a session key used for symmetric block
cipher over the Bluetooth channel. This also resolves the issue of
needing to formulate the payment request before the NFC.

As an aside, in other scenarios, such as an automated dispenser, this
presumption does not hold. The merchant is not present to guard against
device tampering. Those scenarios can be secured using BIP70, but cannot
guarantee privacy.

The other differences I have with the proposal pertain to efficiency,
not privacy or integrity of the transaction:

The proposed resource name is redundant with any unique identifier for
the session. For example, the "h" parameter is sufficient. But with the
establishment of a session key both as I propose above, the parties can
derive a sufficiently unique public resource name from a hash of the
key. An additional advantage is that the resource name can be
fixed-length, simplifying the encoding/decoding.

The MAC address (and resource name) should be encoded using base58. This

The MAC address (and session key) should be encoded using base58. This


As I mentioned in my other e-mail, I don't know that we can consider this NFC a private channel, so I don't think a session key should be transmitted over it.




is shorter than base16, is often shorter than base=
64, better
standardized and does not require URI encoding, and is generally
available to implementers.

There is no need for the establishment of two Bluetooth services.

I would change the payment_url recommendation so that the list order
represents a recommended ordering provided by the terminal for the wallet=
=2E

I wrote up my thoughts on these considerations last year and recently
revised it by adding a section at the end to incorporate the "r" and
"payment_url" generalizations from Andreas and Andy.


The order is set so that it maintains backwards compatibility by providing the https request first. As mentioned in the proposal, the order of the r parameters has the recommended (but not required) priority. The wallet is encouraged to use the same protocol (but not required).



https://github.com/evoskuil/bips/tree/master/docs

e


On 02/22/2015 11:08 AM, 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 opt=
ionally
receive the sender's transaction via Bluetooth, so if the sender wallet
supports it, the sender can be completely offline. Only the terminal need=
s an
internet connection.

Typical scenario envisioned: Customer taps their smartphone (or maybe sma=
rtwatch
in the future) on the NFC pad, confirms the transaction on their phone
(or smartwatch) and the transaction completes via Bluetooth and/or the ph=
one'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 stuf=
f - are
custom extensions of Schildbach's wallet which are not yet standard.

I'm writing this post to document my experience implementing NFC and offl=
ine
payments and hope to move the discussion forward around standardizing som=
e 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] a=
re
relevant here as well.


## NFC vs Bluetooth vs NFC+Bluetooth ##

Before I get into the implementation details, a few words for why I decid=
ed 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 c=
onfirms
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 ta=
ps
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 r=
ight
now, but there are pros and cons to all options. One disadvantage of opti=
on 3 in
practice is, that many users - in my experience - have Bluetooth turned o=
ff, so
it can result in additional UI dialogs popping up, asking the user to tur=
n on
Bluetooth.

Regarding doing everything via Bluetooth or maybe BLE: I have been follow=
ing 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 reques=
t comes
to me through the air and I figure out whether it is meant for me/is legi=
timate".


## NFC data formats ##

A bit of background for those who are not that familiar with NFC: Most Bi=
tcoin
wallets with NFC support make use of NDEF (NFC Data Exchange Format) as f=
ar 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 record=
 types,
among them 'URI' and 'Mime Type'.

A common way of using NFC with Bitcoin is to create a URI record that con=
tains a
Bitcoin URI. Beyond that Schildbach's wallet (and maybe others?) also sup=
port
the mime type record, which is then set to 'application/bitcoin-paymentre=
quest'
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 scena=
rios to
consider below. Not every possible combination is listed, but it should c=
over 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 HTTP
   Example QR code: bitco=
in:1asdf...?amount=3D42&r=3Dhttps://example.org/bip70paymentrequest

4) Touch NFC pad, fetch BIP70 details via HTTP, post transaction via HTTP=

   Example NFC URI: bitco=
in:1asdf...?amount=3D42&r=3Dhttps://example.org/bip70paymentrequest

5) Touch NFC pad, receive BIP70 details directly, post transaction via HT=
TP
   Example NFC MIME record: application/bitcoin-paymentrequest + BIP70 pa=
yment request

6) Scan QR code, fetch BIP70 details via Bluetooth, post transaction via =
Bluetooth
   Example QR code: bitcoin:1asdf...?amount=3D42&am=
p;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&am=
p;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 s=
hould
use an NFC URI record or already provide the complete BIP70 payment reque=
st via
NFC.

My experience here has been, that the latter was fairly fragile in my set=
up
(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 w=
ould
often not complete if I didn't hold the phone perfectly in place. So I qu=
ickly
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 ro=
bust 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 probabl=
y 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 swi=
tch to
scenario 5.

Scenarios 6 and 7 is what the terminal is doing right now. The 'bt' param=
eter is
the non-standard extension of Andreas' wallet that I was mentioning. TBIP=
75
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 i=
s a
good idea and would express my vote for this proposal. So the QR code or =
NFC URI
would then look something like this:

  bit=
coin:1asdf...?amount=3D42&r=3Dhttps://example.org/bip70&r1=3Dbt:1=
234567890AB/resource

In addition the payment request would need to list additional 'payment_ur=
l'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 'repeat=
ed
string payment_url'. If this isn't causing any problems (and hopefully no=
t too
much confusion?) I guess that would be fine too.

In my opinion a wallet should then actually attempt all or multiple of th=
e
provided mechanisms in parallel (e.g. try to fetch the BIP70 payment requ=
est via
both HTTP and Bluetooth) and go with whatever completes first. But that i=
s 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 the
Bluetooth channel even if the BIP70 payment request isn't signed. This wo=
uld
have also been my suggestion, although I know that Mike Hearn has raised
concerns about this approach. One being, that one needs to finalize the B=
IP70
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 st=
ring
payment_url' or would you rather introduce a new field 'additional_paymen=
t_urls'?

2) @Andreas: Is the r, r1, r2 mechanism already implemented in Bitcoin Wa=
llet?

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=
=2Email-archive.com/bitcoin-development%40lists.sourceforge.net/msg06354.=
html
[3] https://github.com/AndySchrod=
er/bips/blob/master/tbip-0074.mediawiki
[4] https://github.com/AndySchrod=
er/bips/blob/master/tbip-0075.mediawiki

-------------------------------------------------------------------------=
-----
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & =
more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.d=
oubleclick.net/gampad/clk?id=3D190641631&iu=3D/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/l=
istinfo/bitcoin-development



      

      

      

      

      

      
----------------------------------------------------=
--------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & =
more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.d=
oubleclick.net/gampad/clk?id=3D190641631&iu=3D/4140/ostg.clktrk
      

      

      

      
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/l=
istinfo/bitcoin-development


    

    

  


--------------050805020100070201090000--

--Vlthew3OPu94VSLtQ2nOQHjjiePehW1wt
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/

iQEcBAEBAgAGBQJU6merAAoJEDT679stRBhrhbUH/1sMaf65ttM/euTHcV6AQBte
jqFA4m/PvcnnckbkjdB0Nupu7kbzIPYG4Uf4lpkXV67eNIKKb9XWMRs6p8J9AEM4
OLjYMfUp8/elwF3hcFYTnoPP6kY4khXDYUOvgELCZja7EfLBrfeMtrwlDy53AApH
ytC13bRItJ7zXfJ837eqIYRfhBQp2Y7NcgyMaXKEZRM8qtUTLnwkLLUuYLyqiumT
ikLMwQ/wHQZrmmMdZNH07awBLeAiI9wk7Dy3Qr5r9zfKygBRdUPAOj4zDYUcb0T7
RS4LDaMChE9nT7oXmXe9cLgDYVYxYUgbylZCdo3iocZtWBwrJW9spCuhZ2Zqdjw=
=aYuk
-----END PGP SIGNATURE-----

--Vlthew3OPu94VSLtQ2nOQHjjiePehW1wt--