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
|
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 1W7r1S-0005w9-Fb
for bitcoin-development@lists.sourceforge.net;
Mon, 27 Jan 2014 18:35:02 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.182 as permitted sender)
client-ip=209.85.214.182; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f182.google.com;
Received: from mail-ob0-f182.google.com ([209.85.214.182])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1W7r1Q-0008CB-M0
for bitcoin-development@lists.sourceforge.net;
Mon, 27 Jan 2014 18:35:01 +0000
Received: by mail-ob0-f182.google.com with SMTP id wm4so6844711obc.41
for <bitcoin-development@lists.sourceforge.net>;
Mon, 27 Jan 2014 10:34:55 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.22.33 with SMTP id a1mr1374693obf.60.1390847695155; Mon,
27 Jan 2014 10:34:55 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.99.112 with HTTP; Mon, 27 Jan 2014 10:34:55 -0800 (PST)
In-Reply-To: <lc67sl$h3$1@ger.gmane.org>
References: <lc5hmg$1jh$1@ger.gmane.org>
<CANEZrP3POX5SACS18_rrQxx=mzmthrM418zmd8Z7-5CBNFSW4Q@mail.gmail.com>
<lc67sl$h3$1@ger.gmane.org>
Date: Mon, 27 Jan 2014 19:34:55 +0100
X-Google-Sender-Auth: fGZBJJpbiJTN4_CPlvk6id_xgf0
Message-ID: <CANEZrP0WkmtugRnzU2omZ6OXcc+DcGGvnpj3afgrMLgbFSf8Ag@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Andreas Schildbach <andreas@schildbach.de>
Content-Type: multipart/alternative; boundary=001a1133177cce854f04f0f7f6ec
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: 1W7r1Q-0008CB-M0
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 18:35:02 -0000
--001a1133177cce854f04f0f7f6ec
Content-Type: text/plain; charset=UTF-8
On Mon, Jan 27, 2014 at 7:18 PM, Andreas Schildbach
<andreas@schildbach.de>wrote:
> I'm not saying I'm against signed payment requests, but unfortunately
> they are just too big for QR-codes. Then again, QR-codes *can* take up
> to 2 KB. How big would a very basic trust chain plus signature be?
>
As I said, the test requests generated by Gavin's generator end up being
about 4kb.
Unfortunately most certs are using RSA keys which aren't very compact. You
can get ECC certs, but for whatever reason, the test requests aren't using
one.
> I was under the impression that addresses will go away. Can you
> elaborate on the mechanism?
>
There's still an address in the URI for backwards compatibility, right? In
theory if everyone some day uses wallets that support BIP70 it'd be
superfluous and could be removed, but whilst it's there, we could find
alternative uses for it ...
> Ok, that's good news (to me). However, you are going to manage trust
> stores (adding and revoking) without TCP?
>
Trust store is just a local database. Why would it involve TCP?
> Well I'm thinking the other way round. Use Bitcoin where its already
> used today -- face to face.
>
Maybe in Berlin :-) Most of my transactions are sadly with online shops,
still.
> > you probably still would like a receipt if you buy
> > something from a local market trader.
>
> Yes, but where is the problem?
>
A receipt is a proof of purchase. If the payment request isn't signed then
it proves nothing as you could have made it yourself. Of course paper
receipts are forgeable too - we sort of pretend receipt
fraud<http://en.wikipedia.org/wiki/Return_fraud>does not exist, but it
does.
Nobody would ever be forced to sign to receive money, obviously, but it's
better if people do as it leads to herd immunity. If people expect to see
it then they will be suspicious if an attacker strips the signing data. If
it's randomly hit/miss then the signing data can just be deleted by a MITM
and you'd never think anything was amiss.
And again, how is he going to provide the payment request to the payer
> without TCP?
>
Over Bluetooth, perhaps. That's what we're talking about, right?
> Interesting, did not know about this BIP. However I don't understand the
> usecase.
It was proposed by the BitPay guys. I think they feel that scanning a QR
code should always make something intelligent happen, even if you don't
(for instance) have a wallet app installed at all. Overloading the URL so
it works for both web browsers and wallet apps is easy, so I can see why
they suggested it. Doesn't seem like a big deal either way.
--001a1133177cce854f04f0f7f6ec
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Jan 27, 2014 at 7:18 PM, Andreas Schildbach <span dir=3D"ltr"><<a hr=
ef=3D"mailto:andreas@schildbach.de" target=3D"_blank">andreas@schildbach.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"><div class=3D"im"><span style=3D"color:rgb(34,34,34)">I=
9;m not saying I'm against signed payment requests, but unfortunately</=
span><br>
</div>
they are just too big for QR-codes. Then again, QR-codes *can* take up<br>
to 2 KB. How big would a very basic trust chain plus signature be?<br></blo=
ckquote><div><br></div><div>As I said, the test requests generated by Gavin=
's generator end up being about 4kb.</div><div><br></div><div>Unfortuna=
tely most certs are using RSA keys which aren't very compact. You can g=
et ECC certs, but for whatever reason, the test requests aren't using o=
ne.</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">
<div class=3D"im"><span style=3D"color:rgb(34,34,34)">I was under the impre=
ssion that addresses will go away. Can you</span><br></div>
elaborate on the mechanism?<br></blockquote><div><br></div><div>There's=
still an address in the URI for backwards compatibility, right? In theory =
if everyone some day uses wallets that support BIP70 it'd be superfluou=
s and could be removed, but whilst it's there, we could find alternativ=
e uses for it ...</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">
<div class=3D"im"><span style=3D"color:rgb(34,34,34)">Ok, that's good n=
ews (to me). However, you are going to manage trust</span><br></div>
stores (adding and revoking) without TCP?<br></blockquote><div><br></div><d=
iv>Trust store is just a local database. Why would it involve TCP?</div><di=
v>=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-left=
-style:solid;padding-left:1ex">
<div class=3D"im"><span style=3D"color:rgb(34,34,34)">Well I'm thinking=
the other way round. Use Bitcoin where its already</span><br></div>
used today -- face to face.<br></blockquote><div><br></div><div>Maybe in Be=
rlin :-) Most of my transactions are sadly with online shops, still.</div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex">
<div class=3D"im">> you probably still would like a receipt if you buy<b=
r>
> something from a local market trader.<br>
<br>
</div>Yes, but where is the problem?<br></blockquote><div><br></div><div>A =
receipt is a proof of purchase. If the payment request isn't signed the=
n it proves nothing as you could have made it yourself. Of course paper rec=
eipts are forgeable too - we sort of pretend <a href=3D"http://en.wikipedia=
.org/wiki/Return_fraud">receipt fraud</a> does not exist, but it does.</div=
>
<div><br></div><div><div>Nobody would ever be forced to sign to receive mon=
ey, obviously, but it's better if people do as it leads to herd immunit=
y. If people expect to see it then they will be suspicious if an attacker s=
trips the signing data. If it's randomly hit/miss then the signing data=
can just be deleted by a MITM and you'd never think anything was amiss=
.</div>
</div><div><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">
<div class=3D"im"><span style=3D"color:rgb(34,34,34)">And again, how is he =
going to provide the payment request to the payer</span><br></div>
without TCP?<br></blockquote><div><br></div><div>Over Bluetooth, perhaps. T=
hat's what we're talking about, right?</div><div>=C2=A0<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pad=
ding-left:1ex">
<div class=3D"im"><span style=3D"color:rgb(34,34,34)">Interesting, did not =
know about this BIP. However I don't understand the</span><br></div>
usecase.</blockquote><div><br></div><div>It was proposed by the BitPay guys=
. I think they feel that scanning a QR code should always make something in=
telligent happen, even if you don't (for instance) have a wallet app in=
stalled at all. Overloading the URL so it works for both web browsers and w=
allet apps is easy, so I can see why they suggested it. Doesn't seem li=
ke a big deal either way.=C2=A0</div>
<div>=C2=A0</div></div></div></div>
--001a1133177cce854f04f0f7f6ec--
|
