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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
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 1WQbxT-0001Ly-FH
for bitcoin-development@lists.sourceforge.net;
Thu, 20 Mar 2014 12:20:27 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.171 as permitted sender)
client-ip=209.85.214.171; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f171.google.com;
Received: from mail-ob0-f171.google.com ([209.85.214.171])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WQbxR-0006qW-Me
for bitcoin-development@lists.sourceforge.net;
Thu, 20 Mar 2014 12:20:27 +0000
Received: by mail-ob0-f171.google.com with SMTP id wn1so767704obc.16
for <bitcoin-development@lists.sourceforge.net>;
Thu, 20 Mar 2014 05:20:20 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.122.133 with SMTP id ls5mr6241971obb.52.1395318020354;
Thu, 20 Mar 2014 05:20:20 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.231 with HTTP; Thu, 20 Mar 2014 05:20:20 -0700 (PDT)
In-Reply-To: <20140320121221.GA25052@netbook.cypherspace.org>
References: <lc5hmg$1jh$1@ger.gmane.org> <leuunm$tjk$1@ger.gmane.org>
<CANEZrP3nQfvDArKTRgje0Cus4G2JD_zpxSjA3fXfxM2TNAP80Q@mail.gmail.com>
<CALDj+BafD+6KTNcYDBEu5gNPzYozSkiC-JCxrY-PzXL2DYBRsw@mail.gmail.com>
<CAJHLa0N4J_Z907+D0ENSNKfNAW2N=7Jf4JzSCO=SU558GtGTzA@mail.gmail.com>
<lge7nk$3mf$2@ger.gmane.org>
<CANEZrP0J849oDvMWjf8LWi0xj44Q8DaUwDip5_smVBMNgeQ3mw@mail.gmail.com>
<20140320121221.GA25052@netbook.cypherspace.org>
Date: Thu, 20 Mar 2014 13:20:20 +0100
X-Google-Sender-Auth: aq0_n5F-lnwgAv-Y2OMswPXC_Cc
Message-ID: <CANEZrP30auwsdGy=HKYbawajOJ8Beu8VwVPn+ZM16L2LCZY7iw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Adam Back <adam@cypherspace.org>
Content-Type: multipart/alternative; boundary=001a1134a7e4f3ba1004f508ca83
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: 1WQbxR-0006qW-Me
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Andreas Schildbach <andreas@schildbach.de>
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: Thu, 20 Mar 2014 12:20:27 -0000
--001a1134a7e4f3ba1004f508ca83
Content-Type: text/plain; charset=UTF-8
Very, very limited. The more data you stuff in them, the less reliable and
slower scanning becomes. A URL is about the limit of what's practically
achievable. Even with that, BitPay have been complaining about the
increased character length from adding the https url to download the
payment request (though not escaping reduces character count by a lot and
is valid).
X.509 is extremely bloated, partly due to the number of features it
supports, partly due to its history but mostly due to the widespread use of
RSA which generates giant keys and signatures. Of course you can get ECC
certs as well, but in practice most merchants don't seem to use them yet.
There's no way you can fit a cert chain into a QR code.
However, this is no big deal, because for the serverless PoS device case
Alex cares about you need a backchannel to submit the transaction and
refund address anyway, so Bluetooth is already useful/required. Downloading
the payment request via it as well as uploading the response is not a big
change and - as mentioned - already implemented by Andreas and myself some
time ago.
On Thu, Mar 20, 2014 at 1:12 PM, Adam Back <adam@cypherspace.org> wrote:
> Whats a sensible limit on practical/convenient QR code size?
>
> How much of the payment protocol message size comes from use of x509?
>
> (Just exploring what the options are).
>
> Adam
>
>
> On Thu, Mar 20, 2014 at 11:36:09AM +0100, Mike Hearn wrote:
>
>> Encoding entire payment requests into qrcodes is definitely not the way
>> to go. They can already be large when signed and we're just at the
>> start of adding features.
>> Finishing off and standardising the bluetooth support is the way to go
>> (r=bt:mac). Andreas' app already has some support for this I believe,
>> so Alex you could prototype with that, but we need to:
>> 1) Add an encryption/auth layer on top, because it runs over RFCOMM
>> sockets. The authentication would require proof of owning the Bitcoin
>> key that's in the address part of the URI (which is needed for
>> backwards compat anyway).
>> 2) Write a BIP for it and make sure it's interoperable
>> For the auth layer we could either use SSL and then just ignore the
>> server certificate and require signing of the session public key with
>> the Bitcoin key, which should be easy to code up but is rather heavy on
>> the air, or roll a custom lightweight thing where we just do a basic
>> ECDH, with the servers key being the same as the address key. But
>> rolling such protocols is subtle and I guess it'd need to be reviewed
>> by people familiar with such things.
>> This feels like a good opportunity to grow the community - perhaps we
>> can find a volunteer in the forums who enjoys crypto.
>>
>
--001a1134a7e4f3ba1004f508ca83
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Very, very limited. The more data you stuff in them, the l=
ess reliable and slower scanning becomes. A URL is about the limit of what&=
#39;s practically achievable. Even with that, BitPay have been complaining =
about the increased character length from adding the https url to download =
the payment request (though not escaping reduces character count by a lot a=
nd is valid).<div>
<br></div><div>X.509 is extremely bloated, partly due to the number of feat=
ures it supports, partly due to its history but mostly due to the widesprea=
d use of RSA which generates giant keys and signatures. Of course you can g=
et ECC certs as well, but in practice most merchants don't seem to use =
them yet. There's no way you can fit a cert chain into a QR code.</div>
<div><br></div><div>However, this is no big deal, because for the serverles=
s PoS device case Alex cares about you need a backchannel to submit the tra=
nsaction and refund address anyway, so Bluetooth is already useful/required=
. Downloading the payment request via it as well as uploading the response =
is not a big change and - as mentioned - already implemented by Andreas and=
myself some time ago.</div>
<div><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Thu, Mar 20, 2014 at 1:12 PM, Adam Back <span dir=3D"ltr"><<a=
href=3D"mailto:adam@cypherspace.org" target=3D"_blank">adam@cypherspace.or=
g</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Whats a sensible limit on practical/convenie=
nt QR code size?<br>
<br>
How much of the payment protocol message size comes from use of x509?<br>
<br>
(Just exploring what the options are).<span class=3D"HOEnZb"><font color=3D=
"#888888"><br>
<br>
Adam</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
On Thu, Mar 20, 2014 at 11:36:09AM +0100, Mike Hearn wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
=C2=A0 Encoding entire payment requests into qrcodes is definitely not the =
way<br>
=C2=A0 to go. They can already be large when signed and we're just at t=
he<br>
=C2=A0 start of adding features.<br>
=C2=A0 Finishing off and standardising the bluetooth support is the way to =
go<br>
=C2=A0 (r=3Dbt:mac). Andreas' app already has some support for this I b=
elieve,<br>
=C2=A0 so Alex you could prototype with that, but we need to:<br>
=C2=A0 1) Add an encryption/auth layer on top, because it runs over RFCOMM<=
br>
=C2=A0 sockets. The authentication would require proof of owning the Bitcoi=
n<br>
=C2=A0 key that's in the address part of the URI (which is needed for<b=
r>
=C2=A0 backwards compat anyway).<br>
=C2=A0 2) Write a BIP for it and make sure it's interoperable<br>
=C2=A0 For the auth layer we could either use SSL and then just ignore the<=
br>
=C2=A0 server certificate and require signing of the session public key wit=
h<br>
=C2=A0 the Bitcoin key, which should be easy to code up but is rather heavy=
on<br>
=C2=A0 the air, or roll a custom lightweight thing where we just do a basic=
<br>
=C2=A0 ECDH, with the servers key being the same as the address key. But<br=
>
=C2=A0 rolling such protocols is subtle and I guess it'd need to be rev=
iewed<br>
=C2=A0 by people familiar with such things.<br>
=C2=A0 This feels like a good opportunity to grow the community - perhaps w=
e<br>
=C2=A0 can find a volunteer in the forums who enjoys crypto.<br>
</blockquote>
</div></div></blockquote></div><br></div>
--001a1134a7e4f3ba1004f508ca83--
|
