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
|
Return-Path: <hearn@vinumeris.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 655F540F
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 20 Jul 2015 13:46:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com
[209.85.223.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6A8571BF
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 20 Jul 2015 13:46:40 +0000 (UTC)
Received: by iecri3 with SMTP id ri3so22693136iec.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 20 Jul 2015 06:46:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=vinumeris.com; s=google;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=MGQ1O3CKEKLw7/4HTtOL2cbrlM3l+YnCRDbmik0YXBE=;
b=R0Coi7z0pE2yYShdmdxqvCITQSLe1rSiHzJHpyyG+mZGBf10Y7M0+7MnHkxKCYQoka
l+p9136ACH5rqCgeAMlAvQgOjUcSupUvcHPS7sp3NAq+OQ5KJdKdSpakrjwwiFmWJLAS
+0e/Ze8XHQh4X0fBE+OJFDMuUi0QjfglayzP0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=MGQ1O3CKEKLw7/4HTtOL2cbrlM3l+YnCRDbmik0YXBE=;
b=eY2qkejguB3MR/dbGyzljXQgnJ4KEg6Ccd+vRXA1h7Irfh17rPjKC9BzgpNzUoc8qS
P1kZMYAeUx44/LxVN3e2x8zDtBksBbtTJcKi9/8bAEtCcqYbz+Rf99D5P1UEbmViFg0F
MN+Dd1Hd8X6lQuH/OCeKpsPZewFJ0RWFXBTXJFjkX4VMRAcO1hLLI4LLtinDMEEouBh1
X+UI4JpFSoU6TPljnQQZF6WhiZT0Gly4dZPVJzlig+oerXaM1Td5OXN2rigsjaHFbtXv
2V2rOKIsIIt5RLhwAK/cYHo1HAIGoGPnD3wf9OeI8jqjGaFa727/pYvP5zT2BBxcOM9I
XHxQ==
X-Gm-Message-State: ALoCoQnGZPoxSbASQWjqWwnO+AADCRqn4INSse5YxtkcN9XuwQ2u48/5WN0h8077TvzLhAusfi9y
MIME-Version: 1.0
X-Received: by 10.107.129.215 with SMTP id l84mr19716914ioi.78.1437399999812;
Mon, 20 Jul 2015 06:46:39 -0700 (PDT)
Received: by 10.50.108.111 with HTTP; Mon, 20 Jul 2015 06:46:39 -0700 (PDT)
In-Reply-To: <55AB8785.4080201@electrum.org>
References: <CA+w+GKQbOMz5nb_SnLB6Xb0FYzNZ_rEj5nbNjm2jY0+L8JJGAA@mail.gmail.com>
<55A4AF62.4090607@electrum.org>
<CA+w+GKRCPEUezaTb46pzuDNxKNgi_KdTW2dOn9hsHwgD159czw@mail.gmail.com>
<55AB8785.4080201@electrum.org>
Date: Mon, 20 Jul 2015 15:46:39 +0200
Message-ID: <CA+w+GKTtkYUst0UJa6364LqBRqWYrA+fOKed973mQCQS4ze=4Q@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: Thomas Voegtlin <thomasv@electrum.org>, Jeff Garzik <jgarzik@gmail.com>
Content-Type: multipart/alternative; boundary=001a113ec6ac63b1cf051b4ec4ff
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jul 2015 13:46:41 -0000
--001a113ec6ac63b1cf051b4ec4ff
Content-Type: text/plain; charset=UTF-8
Hey Thomas,
Was great to hang out with you in Berlin last week!
> Bitcoin addresses do not require a webserver. If we want to build
> something that competes with that, we should have at least that level of
> convenience.
>
Absolutely agree! Convenience for the user is an absolute must. I just
don't know how to let users exchange large data packets without some kind
of server acting as a dropbox in the middle. That leaves two solutions:
1) Set up a way for users to exchange large data packets by using other
people's web servers, e.g. with no user visible signup flow (pure p2p/done
automatically in the background by user wallets)
2) Make the data packets small instead.
We can debate better signing methods that work towards (2). The reason I am
unsure about this is that the point of BIP70 is to be extended with useful
features. Even if we find a way to squeeze a human-meaningful
signature/cert into a URI, that's only one of BIP70s features. The next set
we want to add might end up running out of space again.
A lot of the problems come from how limited QR codes are. So perhaps there
is also a third approach: either find a better replacement for QR codes
(maybe something that uses colour like Microsoft Tag
<http://tag.microsoft.com/what-is-tag/home.aspx>), or drop them as a design
constraint.
Calling Jeff Garzik, Jeff, are you there? I recall BitPay did some
experiments to find out how much data you can stuff into a QR code before
it hurts scannability too much, do you have a writeup anywhere?
This is the main reason I feel uneasy about anything that isn't "build a
store+forward network". QR codes are so fundamental to our ecosystem, but
sooooooo limited, that I'm not sure how else to move forward. We were told
when designing BIP70 that even putting a URL in the QR code is pushing it!
There was talk of compressing the URL in some way. So adding even an ECC
signature which is much longer seems risky.
We can imagine a parallel universe where our societies technology was more
NFC oriented: laptops had NFC tags in them, phones had better NFC support
etc. Then we would have more bytes to play with and we wouldn't face this
pointer-indirection problem :( But laptops don't have the hardware and
Apple sits on their NFC API because they can't imagine any use case that
isn't credit cards :( :(
To get more specific, DNSSEC uses RSA 1024 bit. This causes two problems:
1. A DNSSEC proof is large, bytes wise. Even a single RSA signature
won't fit nicely in a QR code, I think.
2. 1024 bit is the absolute minimum strength you can get away with,
really. DNSSEC assumes frequent key rotations to try and help, which
complicates things.
So I'm not sure using DNSSEC fixes the usability problem we want to fix.
I will do a separate reply to break out some thoughts on replacing QR codes.
Would it be possible to create the same kind of "lightweight payment
> requests" using SSL certificates? Probably, if the final signing key is
> a EC key, and if the payment request does not include the whole chain of
> certificates.
Given that the pre-existing value of the PKI is much lower for individuals
than for companies/websites, where they all have certs already, building a
Bitcoin-specific or entirely new/independent PKI for people is not so
unthinkable, I agree.
In theory such a cert could be as minimal as:
<ECC signature>thomasv@electrum.org
so literally just a signature + a UTF-8 string, and that's it! You don't
need anything more if you're willing to sacrifice extensibility,
revocability, etc.
The pubkey of the CA would be obtained by running the pubkey recovery
algorithm on the signature, and then checked against a table of trusted
pubkeys.
--001a113ec6ac63b1cf051b4ec4ff
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hey Thomas,<div><br></div><div>Was great to hang out with =
you in Berlin last week!</div><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Bitcoin addresses =
do not require a webserver. If we want to build<br>
something that competes with that, we should have at least that level of<br=
>
convenience.<br></blockquote><div><br></div><div>Absolutely agree! Convenie=
nce for the user is an absolute must. I just don't know how to let user=
s exchange large data packets without some kind of server acting as a dropb=
ox in the middle. That leaves two solutions:</div><div><br></div><div>1) Se=
t up a way for users to exchange large data packets by using other people&#=
39;s web servers, e.g. with no user visible signup flow (pure p2p/done auto=
matically in the background by user wallets)</div><div><br></div><div>2) Ma=
ke the data packets small instead.</div><div><br></div><div>We can debate b=
etter signing methods that work towards (2). The reason I am unsure about t=
his is that the point of BIP70 is to be extended with useful features. Even=
if we find a way to squeeze a human-meaningful signature/cert into a URI, =
that's only one of BIP70s features. The next set we want to add might e=
nd up running out of space again.</div><div>=C2=A0</div><div>A lot of the p=
roblems come from how limited QR codes are. So perhaps there is also a thir=
d approach: either find a better replacement for QR codes (maybe something =
that uses colour like <a href=3D"http://tag.microsoft.com/what-is-tag/home.=
aspx">Microsoft Tag</a>), or drop them as a design constraint.</div><div><b=
r></div><div>Calling Jeff Garzik, Jeff, are you there? I recall BitPay did =
some experiments to find out how much data you can stuff into a QR code bef=
ore it hurts scannability too much, do you have a writeup anywhere?</div><d=
iv><br></div><div>This is the main reason I feel uneasy about anything that=
isn't "build a store+forward network". QR codes are so funda=
mental to our ecosystem, but sooooooo limited, that I'm not sure how el=
se to move forward. We were told when designing BIP70 that even putting a U=
RL in the QR code is pushing it! There was talk of compressing the URL in s=
ome way. So adding even an ECC signature which is much longer seems risky.<=
/div><div><br></div><div>We can imagine a parallel universe where our socie=
ties technology was more NFC oriented: laptops had NFC tags in them, phones=
had better NFC support etc. Then we would have more bytes to play with and=
we wouldn't face this pointer-indirection problem :( But laptops don&#=
39;t have the hardware and Apple sits on their NFC API because they can'=
;t imagine any use case that isn't credit cards :( :(</div><div><br></d=
iv><div>To get more specific, DNSSEC uses RSA 1024 bit. This causes two pro=
blems:</div><div><ol><li>A DNSSEC proof is large, bytes wise. Even a single=
RSA signature won't fit nicely in a QR code, I think.<br><br></li><li>=
1024 bit is the absolute minimum strength you can get away with, really. DN=
SSEC assumes frequent key rotations to try and help, which complicates thin=
gs.</li></ol></div><div>So I'm not sure using DNSSEC fixes the usabilit=
y problem we want to fix.</div><div><br></div><div>I will do a separate rep=
ly to break out some thoughts on replacing QR codes.</div><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">Would it be possible to create the same kind o=
f "lightweight payment<br>
requests" using SSL certificates? Probably, if the final signing key i=
s<br>
a EC key, and if the payment request does not include the whole chain of<br=
>
certificates. </blockquote><div><br></div><div>Given that the pre-existing =
value of the PKI is much lower for individuals than for companies/websites,=
where they all have certs already, building a Bitcoin-specific or entirely=
new/independent PKI for people is not so unthinkable, I agree.=C2=A0</div>=
<div><br></div><div>In theory such a cert could be as minimal as:</div><div=
><br></div><div><ECC signature><a href=3D"mailto:thomasv@electrum.org=
">thomasv@electrum.org</a></div><div><br></div><div>so literally just a sig=
nature + a UTF-8 string, and that's it! You don't need anything mor=
e if you're willing to sacrifice extensibility, revocability, etc.=C2=
=A0</div><div><br></div><div>The pubkey of the CA would be obtained by runn=
ing the pubkey recovery algorithm on the signature, and then checked agains=
t a table of trusted pubkeys.</div></div></div></div>
--001a113ec6ac63b1cf051b4ec4ff--
|
