From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1E86A9C for ; 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 ; 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 ; 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 ; 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 ; 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 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: <55A4AF62.4090607@electrum.org> <55AB8785.4080201@electrum.org> <55AD0669.4040002@electrum.org> In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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)