Message-ID: <54F5063A.1000309@voskuil.org>
Date: Mon, 02 Mar 2015 16:54:18 -0800
From: Eric Voskuil <eric@voskuil.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Andreas Schildbach <andreas@schildbach.de>, 
	bitcoin-development@lists.sourceforge.net
References: <20150222190839.GA18527@odo.localdomain>	<54EA5A1C.2020701@AndySchroder.com>	<54EA60D9.8000001@voskuil.org>	<54EA66F5.2000302@AndySchroder.com>	<mcdu6b$j11$1@ger.gmane.org>	<54EAD884.8000205@AndySchroder.com>	<mcet2t$qav$1@ger.gmane.org>	<54EAFC1C.9080502@voskuil.org>	<CANEZrP0XYfnarvN5H_NeOGyO8RLBSGyGxv7M63MSrAd_HXj1OQ@mail.gmail.com>	<54EBB10D.8020502@voskuil.org>	<CANEZrP1F4tGOQuF6b9JV6_n0YmrzmerPp1WMzQor8BggkgAB5Q@mail.gmail.com>	<54EBC187.2050600@voskuil.org>	<CANEZrP0J9OHBYmty4nSevbA38O6wGcjwnLLQks76+8Wa6GGtGg@mail.gmail.com>
	<mcn3lf$78a$1@ger.gmane.org>
In-Reply-To: <mcn3lf$78a$1@ger.gmane.org>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="OL8B52v3LBUUoB6D001WSbHiWcviekOHu"
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)
--OL8B52v3LBUUoB6D001WSbHiWcviekOHu
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 02/26/2015 04:30 AM, Andreas Schildbach wrote:
> On 02/24/2015 11:41 AM, Mike Hearn wrote:
>> On 02/23/2015 04:10 PM, Eric Voskuil wrote:
>>> Does this not also require the BT publication of the script for a P2S=
H
>>> address?
>>
>> You mean if the URI you're serving is like this?
>>
>>    bitcoin:3aBcD........?bt=3D....
>>
>> Yes it would. I guess then, the server would indicate both the script,=

>> and the key within that script that it wanted to use. A bit more compl=
ex
>> but would still work to save URI space.
>=20
> What if the script doesn't use any key at all?
>=20
> Somehow this "re-using" the fallback address idea feels less and less
> appealing to me. I think we should add our own parameter and let go of
> fallback addresses as soon as possible. If will waste space during the
> transition period, but after that it should make no difference any more=
=2E

Agree. The amount of bitcoin URI space in question isn't a material
issue when it comes to NFC. The more significant considerations here are
the additional BT round trip to establish a session, greater complexity,
and the potential lack of a correlating address (as you point out above).=


On the other hand I think the approach has merit in a scenario where the
bitcoin URI is read from a QR code and BT is available (IOW no NFC).
Generalizing it to the NFC-based bitcoin URI is the problem.

A much cleaner generalization is to rationalize the two approaches
*after* the bitcoin URI has been read (from either NFC or QR). In the QR
scenario the wallet can obtain a verifiable public key from the BT
terminal (subject to some limitations as discussed above). In the NFC
scenario the public key is just passed in the URI. The scenarios come
together at the point where they both have the public key (and the mac
address).

This of course implies that the the BT URL scheme, in order to be used
in both places, would have to allow the public key to be optional. But
in an NFC tap it would be present and in a QR scan it would not.

QR-BT
bitcoin:<bitcoin-address>?bts:<mac-address>

NFC-BT
bitcoin:[bitcoin-address]?bts:<mac-address>/<public-key>

As you say, this prevents the NFC scenario from perpetuating the
fallback address as a requirement, which eventually shortens the bitcoin
URI.

Making the public key a requirement when used with NFC would simplify
wallet development for NFC only wallets. But if a wallet supported both
NFC and QR scanning it wouldn't make much difference. So it's not
unreasonable to think of it like this:

QR-BT/NFC-BT
bitcoin:<bitcoin-address>?bts:<mac-address>
bitcoin:[bitcoin-address]?bts:<mac-address>/<public-key>

This provides greater generality, but it creates a situation where
NFC-only wallets need to support the more complex approach, and where
use in QR codes would have scanning issues. So I think it's better to
specify limits on each as in the first example.

e


--OL8B52v3LBUUoB6D001WSbHiWcviekOHu
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

iQEcBAEBAgAGBQJU9QY7AAoJEDzYwH8LXOFObHYIAIkyuidkbX95mrgNraJt471O
K0uVV4f+lLFbFOTiGhvTuasD6BU4eO4WEUjwwKAVtJaphWTvEy6BHaOGl8y4Fpko
9QO8achIMGxpg41DrGfJBxNyxT1lQWjmmd8ek6YbBNnsdlW4FvsQgJp5hfv/CGwk
0ph/bVykqpqQZUdbuR4zV9vrENW0d+uBLke78UEcdIkH8ATj067i/0wh51xPKPd8
ymw2tPSG0isQsfg1qkaJf8nznpQnhf1gUhlthlWQBNf/qat7JiEic46ERl85zXdZ
RnHknrHj5mlTPfGkJwyXG77gCzdCFb6RKTVj4VB3t6+wiDUj+9RXXyTD9XSd/7Q=
=sT/d
-----END PGP SIGNATURE-----

--OL8B52v3LBUUoB6D001WSbHiWcviekOHu--