path: root/30/722b3858ed32f7c3ec76b88eac474d1b167dcc

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 4922D282
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 19 Jul 2015 11:18:35 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net
	[217.70.183.196])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E77B4E9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 19 Jul 2015 11:18:33 +0000 (UTC)
Received: from mfilter17-d.gandi.net (mfilter17-d.gandi.net [217.70.178.145])
	by relay4-d.mail.gandi.net (Postfix) with ESMTP id CFD5A172089
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 19 Jul 2015 13:18:31 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter17-d.gandi.net
Received: from relay4-d.mail.gandi.net ([217.70.183.196])
	by mfilter17-d.gandi.net (mfilter17-d.gandi.net [10.0.15.180])
	(amavisd-new, port 10024) with ESMTP id e93lHpmbXC0a
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 19 Jul 2015 13:18:30 +0200 (CEST)
X-Originating-IP: 94.223.107.254
Received: from [192.168.2.153]
	(dslb-094-223-107-254.094.223.pools.vodafone-ip.de [94.223.107.254])
	(Authenticated sender: thomasv@electrum.org)
	by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 1D48D172081
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 19 Jul 2015 13:18:29 +0200 (CEST)
Message-ID: <55AB8785.4080201@electrum.org>
Date: Sun, 19 Jul 2015 13:18:29 +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>
In-Reply-To: <CA+w+GKRCPEUezaTb46pzuDNxKNgi_KdTW2dOn9hsHwgD159czw@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: Sun, 19 Jul 2015 11:18:35 -0000

Hi Mike,

The reason why I would like to extend BIP70 is because it is currently
not being used in transactions between end-users. BIP70 works very well
in B2C situations, where users buy products from a website. However,
end-users still share Bitcoin addresses.

Before BIP70 was written, I had proposed "Signed URIs", where the
signature is a public proof that a payee requested a payment. This is
one of the main benefits of BIP70, and I still want to bring it to
user-to-user transactions.

I believe one of the main barriers to BIP70 adoption is that bitcoin:
URIs have been extended in a way that requires the request to be hosted
on a webserver. You may complain about the lack of store-and-forward
network, despite the apparent simplicity of creating one such network.
However, that does not mean we should absolutely do things that way and
wait until such a network exists.

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.

EC signatures are short, and they can be shared by copy-paste, or added
to a bitcoin: URI. This is a features of my "Signed URIs" proposal, that
was lost in BIP70. Indeed, signed URIs were self-contained. A serialized
payment request can also be made very short, if it is signed by a EC
key, and if it does not include the chain of certificates. Such a
"lightweight request" can be base58-encoded, and easily shared by
copy-paste, or passed in a bitcoin: URI.

Size is another reason why I proposed to use DNSSEC in BIP70 (the first
reason is that the subdomain is signed by the domain, not by an external
CA). Indeed, DNSSEC provides a canonical way to download the chain of
signatures needed to verify a record. Thus, the chain of signatures does
not need to be included in the payment request; it can be downloaded and
archived by the verifier.

Now, I understand that SSL vertificates have distinct advantages over
DNSSEC; for example, CA-signed SSL certificates have a legal value,
which is important for dispute resolution.

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. (However, that would require an additional infrastructure
to publish the chain of certificates, and I do not think that x509
certification path are unique, which makes things more complicated, but
not impossible).

Sorry if I did not answer point-by-point to your post. I felt that I
failed to explain one of the reasons why I want to use DNSSEC in the
validation of payment requests.

Thomas




Le 14/07/2015 13:45, Mike Hearn a =C3=A9crit :
> Hi Thomas,
>=20
> Re: NetKi, I think any proposal in this space has to be an open standar=
d,
> almost by the definition of what it is. At any rate, it may be worth
> talking to them. They have signed up to implement their system at least=
.
>=20
> I did understand that your proposal does not rely on email - for instan=
ce a
> web forum could issue username@reddit.com type aliases, even if those a=
re
> not also email accounts. I am just continuing the comparison against em=
ail
> address certs.
>=20
> It's also the case that a domain can use the DKIM setup without actuall=
y
> offering email accounts. They can just have a web form or API that trig=
gers
> sending of the signed email (or simply, providing the signed headers
> themselves). Thus the same system can be used transparently by both ema=
il
> providers and other sites that don't give their users email addresses, =
but
> would still like to use the same system.
>=20
> Hardly anyone uses email certificates today, so I don't think it would
>> affect a lot of users.
>=20
>=20
> No, but obviously we'd like to change that! The holdup is not the
> certificate side of things, really, but rather the lack of a
> store-and-forward network for signed payment requests. I keep asking
> someone to build one but I fear the problem is almost too simple ......
> everyone who looks at this decides to solve 12 other problems
> simultaneously, it gets complicated, then they never launch :(
>=20
> Once there's a simple and robust way to get PaymentRequest's from one e=
nd
> user to another, even when that first user is offline, then getting an
> email cert issued is no big deal.
>=20
> That does not look so... not until (1) BIP70 wallets integrate with
>> https://crt.sh, (2) you convince that service to index email certs (3)
>> you convince all CAs to report all email certs they issue to crt.sh.
>>
>=20
> Any solution that separates identity providers from certificate issuers
> would have these requirements, though. And as many identity providers t=
oday
> do not wish to become CAs too, it seems fundamental.
>=20
> I don't think it's such a problem, mind you. The crt.sh website is actu=
ally
> a frontend to the CT protocol, which is a somewhat blockchain like audi=
t
> log that's eventually intended to contain all issued certificates. Righ=
t
> now, of course, they focus on SSL certs because those are the most comm=
on
> and important. If other kinds of certs became more widely used, support=
 in
> the infrastructure would follow.
>=20
>=20
>=20
> Don't get me wrong - I would like to see a way for a domain to delegate
> BIP70 signing power to a third party. For instance, this would mean pay=
ment
> processors like BitPay could sign on the behalf of the merchant, and th=
e
> merchant identity would then show up in wallets. The "chain a cert off =
a
> domain cert" trick would be a good way to do that, though rather than
> hacking the X.509 stack to validate invalid stuff, at this point it may=
 as
> well be a custom (better) cert format. There's little reason to use X.5=
09
> beyond backwards compatibility.
>=20
> But the most popular identity providers today either don't care about
> Bitcoin at all, or worse, are developing competitors to it. So for real
> adoption to occur, we must have solutions that do not require identity
> provider cooperation. I realise this is a business reason rather than a
> technical reason, but it's a very strong one - so bootstrapping off
> existing infrastructure with a split CA/ID provider design still makes =
much
> more sense to me.
>=20