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
|
Return-Path: <thomasv@electrum.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 4CA9F408
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 20 Jul 2015 14:32:15 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net
[217.70.183.197])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3EF09202
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 20 Jul 2015 14:32:14 +0000 (UTC)
Received: from mfilter44-d.gandi.net (mfilter44-d.gandi.net [217.70.178.175])
by relay5-d.mail.gandi.net (Postfix) with ESMTP id 1767D41C062
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 20 Jul 2015 16:32:12 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter44-d.gandi.net
Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197])
by mfilter44-d.gandi.net (mfilter44-d.gandi.net [::ffff:10.0.15.180])
(amavisd-new, port 10024) with ESMTP id O17ZSbxVBHQu
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 20 Jul 2015 16:32:10 +0200 (CEST)
X-Originating-IP: 85.181.106.214
Received: from [192.168.1.2] (x55b56ad6.dyn.telefonica.de [85.181.106.214])
(Authenticated sender: thomasv@electrum.org)
by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 9FFC441C096
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 20 Jul 2015 16:32:10 +0200 (CEST)
Message-ID: <55AD0669.4040002@electrum.org>
Date: Mon, 20 Jul 2015 16:32:09 +0200
From: Thomas Voegtlin <thomasv@electrum.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
CC: bitcoin-dev@lists.linuxfoundation.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>
<CA+w+GKTtkYUst0UJa6364LqBRqWYrA+fOKed973mQCQS4ze=4Q@mail.gmail.com>
In-Reply-To: <CA+w+GKTtkYUst0UJa6364LqBRqWYrA+fOKed973mQCQS4ze=4Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,MISSING_HEADERS,
RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.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 14:32:15 -0000
hi Mike,
I hope you had a good trip!
> To get more specific, DNSSEC uses RSA 1024 bit. This causes two problem=
s:
>=20
> 1. A DNSSEC proof is large, bytes wise. Even a single RSA signature
> won't fit nicely in a QR code, I think.
>=20
> 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.
>=20
> So I'm not sure using DNSSEC fixes the usability problem we want to fix=
.
>=20
In my previous post, I was suggesting to *not* include the proof in the
request, because the payer can download it independently. Only the final
signature is needed. What makes DNSSEC interesting is not the size of
the proof, but rather the fact that you can request it easily, and in a
canonical way.
A typical lightweight payment request, serialized with EC signature and
without the proof, would be about 150 bytes long.
> I will do a separate reply to break out some thoughts on replacing QR c=
odes.
>=20
> Would it be possible to create the same kind of "lightweight payment
>> requests" using SSL certificates? Probably, if the final signing key i=
s
>> a EC key, and if the payment request does not include the whole chain =
of
>> certificates.
>=20
>=20
> Given that the pre-existing value of the PKI is much lower for individu=
als
> than for companies/websites, where they all have certs already, buildin=
g a
> Bitcoin-specific or entirely new/independent PKI for people is not so
> unthinkable, I agree.
>=20
> In theory such a cert could be as minimal as:
>=20
> <ECC signature>thomasv@electrum.org
>=20
> 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.
Again, we don't have to sacrifice revocability, if the proof is
downloaded separately.
>=20
> 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.
>=20
|
