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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W7lyd-0003AG-1L for bitcoin-development@lists.sourceforge.net; Mon, 27 Jan 2014 13:11:47 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.44 as permitted sender) client-ip=209.85.219.44; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f44.google.com; Received: from mail-oa0-f44.google.com ([209.85.219.44]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1W7lyb-000759-VP for bitcoin-development@lists.sourceforge.net; Mon, 27 Jan 2014 13:11:47 +0000 Received: by mail-oa0-f44.google.com with SMTP id g12so6703307oah.31 for ; Mon, 27 Jan 2014 05:11:40 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.76.227 with SMTP id n3mr379617oew.52.1390828300518; Mon, 27 Jan 2014 05:11:40 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.99.112 with HTTP; Mon, 27 Jan 2014 05:11:40 -0800 (PST) In-Reply-To: References: Date: Mon, 27 Jan 2014 14:11:40 +0100 X-Google-Sender-Auth: lOh-L1NN5hkL9lRqF685GgOYI1M Message-ID: From: Mike Hearn To: Andreas Schildbach Content-Type: multipart/alternative; boundary=047d7b33d8becbccb904f0f37277 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1W7lyb-000759-VP Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 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: Mon, 27 Jan 2014 13:11:47 -0000 --047d7b33d8becbccb904f0f37277 Content-Type: text/plain; charset=UTF-8 Thanks Andreas, that's really interesting work. Comments below. On Mon, Jan 27, 2014 at 12:59 PM, Andreas Schildbach wrote: > Because I could not find any standard for Bluetooth URLs, I made > up my own: "bt:112233445566" means MAC address 11:22:33:44:55:66. I would like to see Bluetooth continue to work for scan-to-pay even in the signed case. So for this reason the current approach with a BTMAC parameter in the Bitcoin URI seems to work universally across NFC tags and QR codes, and would allow download of a signed PaymentRequest even in the case where a QR code is used. Because a Bitcoin URI already contains a public key (hash), re-using that to establish an encrypted/authd connection on top of an insecure RFCOMM socket would seem to be relatively straightforward. > Obviously such QR-encoded payment requests cannot grow in size as much > as using other media. In particular, I expect PKI signed requests are > out of question. However, in face to face payments the value of a sig > based on PKI is highly questionable, and the fact the sig cannot be > verified without TCP connectivity doesn't help. > Just a correction here - the reason signed payment requests are "large" (about 4000 bytes) is exactly because they *can* be verified offline, i.e. by a Trezor. The signed payment request contains all the data needed to establish its authenticity, including certificates and the signature itself. No TCP connection is needed. For face to face payments, I think signing is still useful. For one, we want to keep the distinction between "merchant" and "user" as blurry and indistinct as possible. A strong separation between merchants and consumers is one of the many bad things about the credit card system. Whilst initially we'd expect the payment protocol to be used by online webshops, in future it could be used by little corner shops, children's lemonade stands and so on. You don't want to exclude entire classes of transactions from being secure with Trezor type devices, and besides, even without a Trezor you probably still would like a receipt if you buy something from a local market trader. Another use case - we heard a story about a restaurant owner who accepted Bitcoin. He printed a static bitcoin URI onto a QR code on the menu. A month or two later he discovered one of his waiters had re-printed the menus with his own QR code! The people thought they had been paying for the meal, and in fact it went right into the pocket of the waiter. As to how it works, well, that's not hard. Comodo give away free email address certs with a few mouse clicks, it's no harder than signing up for a website. Then you can just open that cert file on your phone to install it and it should become usable automatically with a future version of bitcoinj. Email address doesn't prove a whole lot, of course, but it's better than nothing. If the restaurant owner had even just a hotmail address, he could have stuck it up behind the bar or painted it on the outside of his shop and some customer would have got suspicious when he didn't see the address (assuming we're successful at deploying it of course). > - I chose to re-use the "bitcoin:" URL scheme > Other wallets won't know what to do with it and would yield a strange error message. > Finally this is the usecase the payment protocol was invented for and > it's not face-to-face. I don't have much to add, just one thing. As a > byproduct of the above, "payment protocol URLs" can be used for links > published on web pages as well. This might provide a nice replacement > for the imho rather ugly BIP72 specification once the payment protocol > is widely deployed. URL length is limited on some versions of internet explorer (probably on all browsers). Rather than pack a file into a URL, if you don't want to use the current r= extension it's better for apps to just register to handle .bitcoinpaymentrequest files / the right MIME type. Downloading it and opening it would do the right thing automatically. Remember BIP 73 also! It says that with the apps built-in QR scanner, if you scan an HTTP[S] URI, you should try downloading it with a magic header. That way you can get a payment request file out of the server. Without the magic header (i.e. a normal generic barcode scanner app) it would open a web page containing a bitcoin URI clickable link. --047d7b33d8becbccb904f0f37277 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Andreas, that's really interesting work. Commen= ts below.

On Mon, Jan 27, 2014 at 12:59 PM, Andreas Schildbach &= lt;andreas@schil= dbach.de> wrote:
Because I could not find any standard for Bluetooth URLs, = I made
up my own: "bt:112233445566" means MAC address 11:22:33:44:55:66.=

I would like to see Bluetooth contin= ue to work for scan-to-pay even in the signed case. So for this reason the = current approach with a BTMAC parameter in the Bitcoin URI seems to work un= iversally across NFC tags and QR codes, and would allow download of a signe= d PaymentRequest even in the case where a QR code is used.

Because a Bitcoin URI already contains a public k= ey (hash), re-using that to establish an encrypted/authd connection on top = of an insecure RFCOMM socket would seem to be relatively straightforward.
=C2=A0
Obviously such QR-encoded payment req= uests cannot grow in size as much
as using other media. In particular, I expect PKI signed requests are
out of question. However, in face to face payments the value of a sig
based on PKI is highly questionable, and the fact the sig cannot be
verified without TCP connectivity doesn't help.
Just a correction here - the reason signed payment requests ar= e "large" (about 4000 bytes) is exactly because they *can* be ver= ified offline, i.e. by a Trezor. The signed payment request contains all th= e data needed to establish its authenticity, including certificates and the= signature itself. No TCP connection is needed.

For face to face payments, I think signing is still use= ful. For one, we want to keep the distinction between "merchant" = and "user" as blurry and indistinct as possible. A strong separat= ion between merchants and consumers is one of the many bad things about the= credit card system. Whilst initially we'd expect the payment protocol = to be used by online webshops, in future it could be used by little corner = shops, children's lemonade stands and so on. You don't want to excl= ude entire classes of transactions from being secure with Trezor type devic= es, and besides, even without a Trezor you probably still would like a rece= ipt if you buy something from a local market trader.

Another use case - we heard a story about a restaurant = owner who accepted Bitcoin. He printed a static bitcoin URI onto a QR code = on the menu. A month or two later he discovered one of his waiters had re-p= rinted the menus with his own QR code! The people thought they had been pay= ing for the meal, and in fact it went right into the pocket of the waiter.<= /div>

As to how it works, well, that's not hard. Comodo g= ive away free email address certs with a few mouse clicks, it's no hard= er than signing up for a website. Then you can just open that cert file on = your phone to install it and it should become usable automatically with a f= uture version of bitcoinj. Email address doesn't prove a whole lot, of = course, but it's better than nothing. If the restaurant owner had even = just a hotmail address, he could have stuck it up behind the bar or painted= it on the outside of his shop and some customer would have got suspicious = when he didn't see the address (assuming we're successful at deploy= ing it of course).
=C2=A0
- I chose to re-use the "bitcoin:&qu= ot; URL scheme

Other wallets won't know what to do wi= th it and would yield a strange error message.
=C2=A0
Finally this is the usecase the payment protocol was invented for and
it's not face-to-face. I don't have much to add, just one thing. As= a
byproduct of the above, "payment protocol URLs" can be used for l= inks
published on web pages as well. This might provide a nice replacement
for the imho rather ugly BIP72 specification once the payment protocol
is widely deployed.

URL length is limited o= n some versions of internet explorer (probably on all browsers). Rather tha= n pack a file into a URL, if you don't want to use the current r=3D ext= ension it's better for apps to just register to handle .bitcoinpaymentr= equest files / the right MIME type. Downloading it and opening it would do = the right thing automatically.

Remember BIP 73 also! It says that with the apps built-= in QR scanner, if you scan an HTTP[S] URI, you should try downloading it wi= th a magic header. That way you can get a payment request file out of the s= erver. Without the magic header (i.e. =C2=A0a normal generic barcode scanne= r app) it would open a web page containing a bitcoin URI clickable link.
--047d7b33d8becbccb904f0f37277--