summaryrefslogtreecommitdiff
path: root/c4/ca7d5fade83dee8b7357474dffdd78e0f0d76d
blob: b75538717355ba6d7b1d7fdfb59af4943b734000 (plain)
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
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 1E86A9C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 20 Jul 2015 14:52:55 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net
	[217.70.183.198])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B28D18D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 20 Jul 2015 14:52:54 +0000 (UTC)
Received: from mfilter18-d.gandi.net (mfilter18-d.gandi.net [217.70.178.146])
	by relay6-d.mail.gandi.net (Postfix) with ESMTP id 3CB70FB952
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 20 Jul 2015 16:52:53 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter18-d.gandi.net
Received: from relay6-d.mail.gandi.net ([217.70.183.198])
	by mfilter18-d.gandi.net (mfilter18-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024) with ESMTP id 2mrsf8vUcP4w
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 20 Jul 2015 16:52:51 +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 relay6-d.mail.gandi.net (Postfix) with ESMTPSA id BA1AEFB887
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 20 Jul 2015 16:52:51 +0200 (CEST)
Message-ID: <55AD0B43.4010207@electrum.org>
Date: Mon, 20 Jul 2015 16:52:51 +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>	<55AD0669.4040002@electrum.org>
	<CA+w+GKSqqD=Fwyptzd_skq3+-x2dFxjY_gOOtEuAo7ZPQ9AzoA@mail.gmail.com>
In-Reply-To: <CA+w+GKSqqD=Fwyptzd_skq3+-x2dFxjY_gOOtEuAo7ZPQ9AzoA@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:52:55 -0000



Le 20/07/2015 16:42, Mike Hearn a =C3=A9crit :
>>
>> In my previous post, I was suggesting to *not* include the proof in th=
e
>> request, because the payer can download it independently. Only the fin=
al
>> 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.
>>
>=20
> Yes, but you still need the final signature. Is it possible to use an E=
C
> signature with DNSSEC? I thought it was an all-RSA system. If I'm wrong
> about that, and all you need is 32 bytes, then my argument does not hol=
d.
>=20

The final signature is a signature of the payment request, it is not
part of DNSSEC. So, yes, that signature can be EC.

The DNSSEC proof is used to verify that the public key, which is
recovered from the signature, corresponds to the alias.

The payment requests I am currently playing with have the following value=
s:

pki_type =3D "dnssec+btc" (btc means that the signature is checked agains=
t
a Bitcoin address stored in DNS)
pki_data =3D the user's alias (DNS key)