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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <timo.hanke@web.de>) id 1U4BUj-00089k-1D
for bitcoin-development@lists.sourceforge.net;
Sat, 09 Feb 2013 14:33:33 +0000
Received: from mout.web.de ([212.227.17.12])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1U4BUi-0001WS-2L for bitcoin-development@lists.sourceforge.net;
Sat, 09 Feb 2013 14:33:32 +0000
Received: from crunch ([93.129.20.196]) by smtp.web.de (mrweb102) with ESMTPA
(Nemesis) id 0Le4Po-1Uj1Xm0dH2-00pkyu;
Sat, 09 Feb 2013 15:33:26 +0100
Date: Sat, 9 Feb 2013 15:33:25 +0100
From: Timo Hanke <timo.hanke@web.de>
To: Peter Todd <pete@petertodd.org>
Message-ID: <20130209143325.GA3998@crunch>
References: <20130208100354.GA26627@crunch>
<20130208110108.GA6893@savin>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20130208110108.GA6893@savin>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Provags-ID: V02:K0:h/oVdBjwT6Htx5m9t4r6A6K9AK5t0dQ4e4TMECyh6sH
FTNmgMGOGGKF7jLO5kM+7oho4mOyBfEi2cmZ9jTPtbcFWk4xcC
1Yn2Z1V3WvGM/PI1bRKHTLrTykP4HseJNI6FX94hPVj98QAOiM
fKcc1J+xziV13WOJLCcbzQlxnUKbqvQoNWI+z9fHPZZdayQvLq
rAA6qUp1/FPmIn0zrww/A==
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(timo.hanke[at]web.de)
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [212.227.17.12 listed in list.dnswl.org]
-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1U4BUi-0001WS-2L
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Blockchain as root CA for payment protocol
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: timo.hanke@web.de
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 09 Feb 2013 14:33:33 -0000
On Fri, Feb 08, 2013 at 06:01:08AM -0500, Peter Todd wrote:
> On Fri, Feb 08, 2013 at 11:03:54AM +0100, Timo Hanke wrote:
> > First, we have drafted a quite general specification for bitcoin certificates (protobuf messages) that allow for a variety of payment protocols (e.g. static as well as customer-side-generated payment addresses).
> > This part has surely been done elsewhere as well and is orthogonal to the goal of this project.
> > What is new here is the signatures _under_ the certificates.
> >
> > We have patched the bitcoind to handle certificates, submit signatures to the blockchain, verify certificates against the blockchain, pay directly to certificates (with various payment methods), revoke certificates.
> > Signatures in the blockchain are stored entirely in the UTXO set (i.e. the unspend, unprunable outputs).
> > This seems to make signature lookup and verification reasonably fast:
> > it took us 10s in the mainnet test we performed (lookup is instant on the testnet, of course).
>
> Why don't you use namecoin or another alt-chain for this?
Because namcoin tries to solve a different problem, DNS, whereas I want
to establish an identity for a payment protocol. Your incoming payments
will land on addresses that are derived (regardless which way) from this
idenity. This makes your identity as important (securitywise) as
anything else involved in the bitcoin protocol. Therefore I would not
want to have payment-ids rely on anything _less_ than bitcoin's own
blockchain. In particular not on PKI with centralized root CAs. But also
not on namecoin or any other (weaker) alt-chains.
You can argue that alt-chains _can_ be as strong as bitcoin, but they
don't _have to_ be. There is no guarantee how many people will
cross-mine. The alt-chain could even disappear at some point. If at some
point your alt-chain is no longer being worked on, then how do you prove
that some old bitcoin transaction went to an address for which there was
a valid id/certificate at the time of sending? If the certificate is
based inside bitcoin's blockchain then you will have a proof for the
correct destinations of all your old transactions as long as bitcoin
exists.
Besides all this, as you mentioned namecoin specifically, that is
overkill if you just want to link two hashes together. A single 2-of-2
multisig output would suffice for that.
> The UTXO set is the most expensive part of the blockchain because it
> must be stored in memory with fast access times. It's good that you have
> designed the system so that the addresses can be revoked, removing them
> from the UTXO set, but it still will encourage the exact same type of
> ugly squatting behavior we've already seen with first-bits, and again
> it'll have a significant cost to the network going forward for purposes
> that do not need to be done on the block chain.
You are probably right that storing this in the _spent outputs_ would be
better. There doesn't seem to be any type of client out there that would
benefit from having to search UTXO only.
Timo
|
