1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <eric@voskuil.org>) id 1YSb6P-0008Ps-Dn
for bitcoin-development@lists.sourceforge.net;
Tue, 03 Mar 2015 00:54:25 +0000
X-ACL-Warn:
Received: from mail-pd0-f173.google.com ([209.85.192.173])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YSb6K-0002eT-AY
for bitcoin-development@lists.sourceforge.net;
Tue, 03 Mar 2015 00:54:25 +0000
Received: by pdbft15 with SMTP id ft15so21512260pdb.11
for <bitcoin-development@lists.sourceforge.net>;
Mon, 02 Mar 2015 16:54:14 -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=MxZAdFmW45Zw5KmtwkYOVZ9kXiGSsHs4B9vDvyYrtE8=;
b=WrEfvlnU9my4VVnvFXeFJINVgbC/kv+H0mND0LSV5eWP1MU54/OziK4Ld6EhSzxXQH
SeHMsO/lKvrijIoVW4zrBMW70eBG8uOJ8BqjbyWYRlk4L0rsVkq64rdfUeqRYdiSaahp
ie4Vx7CIvGrQHDQr+QHtYz/l2OZEKRDjM8nLziGIffzQ1YZrR5XJqCptt7AUdd4xS64Q
dGXqrs+O5sTZXAKTTcQ3aUl73w/wG4LofwwccAgPdnOk+D+ddP8ZecStoW6EF+LhBdQm
5KDUrQmAuJSw/Xin9nMKHePEhliyvt0Tufu1KcOryEEQqGpyfTrm26l1snZ0RhuAKYCn
xRjw==
X-Gm-Message-State: ALoCoQn/ZA5amj6MB9D28T44IvvFywpWk2e/ZDxlV9R1QErIsd6g56MQafCsEDHJL6ELAfLMOD6v
X-Received: by 10.70.138.35 with SMTP id qn3mr50866146pdb.47.1425344054611;
Mon, 02 Mar 2015 16:54:14 -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
nv7sm13136425pdb.54.2015.03.02.16.54.12
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 02 Mar 2015 16:54:13 -0800 (PST)
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"
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: 1YSb6K-0002eT-AY
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 03 Mar 2015 00:54:25 -0000
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--
|
