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
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
|
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 <mh.in.england@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <lc5hmg$1jh$1@ger.gmane.org>
References: <lc5hmg$1jh$1@ger.gmane.org>
Date: Mon, 27 Jan 2014 14:11:40 +0100
X-Google-Sender-Auth: lOh-L1NN5hkL9lRqF685GgOYI1M
Message-ID: <CANEZrP3POX5SACS18_rrQxx=mzmthrM418zmd8Z7-5CBNFSW4Q@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Andreas Schildbach <andreas@schildbach.de>
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 <bitcoin-development@lists.sourceforge.net>
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: <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: 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
<andreas@schildbach.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 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
<div dir=3D"ltr">Thanks Andreas, that's really interesting work. Commen=
ts below.<div><br></div><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e">On Mon, Jan 27, 2014 at 12:59 PM, Andreas Schildbach <span dir=3D"ltr">&=
lt;<a href=3D"mailto:andreas@schildbach.de" target=3D"_blank">andreas@schil=
dbach.de</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">Because I could not find any standard for Bluetooth URLs, =
I made<br>
up my own: "bt:112233445566" means MAC address 11:22:33:44:55:66.=
</blockquote><div><br></div><div><div>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.</div>
</div><div><br></div><div>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.</=
div>
<div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord=
er-left-style:solid;padding-left:1ex">Obviously such QR-encoded payment req=
uests cannot grow in size as much<br>
as using other media. In particular, I expect PKI signed requests are<br>
out of question. However, in face to face payments the value of a sig<br>
based on PKI is highly questionable, and the fact the sig cannot be<br>
verified without TCP connectivity doesn't help.<br></blockquote><div><b=
r></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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>
<div><br></div><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).</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex">- I chose to re-use the "bitcoin:&qu=
ot; URL scheme<br>
</blockquote><div><br></div><div>Other wallets won't know what to do wi=
th it and would yield a strange error message.</div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex">
Finally this is the usecase the payment protocol was invented for and<br>
it's not face-to-face. I don't have much to add, just one thing. As=
a<br>
byproduct of the above, "payment protocol URLs" can be used for l=
inks<br>
published on web pages as well. This might provide a nice replacement<br>
for the imho rather ugly BIP72 specification once the payment protocol<br>
is widely deployed.</blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</d=
iv>
</div></div></div>
--047d7b33d8becbccb904f0f37277--
|
