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
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1U4rRj-0000OT-03
for bitcoin-development@lists.sourceforge.net;
Mon, 11 Feb 2013 11:21:15 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.161 as permitted sender)
client-ip=62.13.148.161; envelope-from=pete@petertodd.org;
helo=outmail148161.authsmtp.com;
Received: from outmail148161.authsmtp.com ([62.13.148.161])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1U4rRe-0002lh-74 for bitcoin-development@lists.sourceforge.net;
Mon, 11 Feb 2013 11:21:14 +0000
Received: from mail-c226.authsmtp.com (mail-c226.authsmtp.com [62.13.128.226])
by punt6.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
r1BBL3E5028178; Mon, 11 Feb 2013 11:21:03 GMT
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r1BBKwlw087947
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Mon, 11 Feb 2013 11:21:01 GMT
Date: Mon, 11 Feb 2013 06:21:03 -0500
From: Peter Todd <pete@petertodd.org>
To: Timo Hanke <timo.hanke@web.de>
Message-ID: <20130211112103.GA7346@savin>
References: <20130208100354.GA26627@crunch> <20130208110108.GA6893@savin>
<20130209143325.GA3998@crunch>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8"
Content-Disposition: inline
In-Reply-To: <20130209143325.GA3998@crunch>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 1df2cc53-743d-11e2-98a9-0025907ec6c5
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdwMUHlAWAgsB AmUbWlVeUlx7WWI7 bAxPbAVDY01GQQRq
WVdMSlVNFUsqAG5z fVlCFRl6cAxCfzBy Z0FjXj5aCBJ4JhV4
QVNTEW5SeGZhPWIC WUgJfh5UcAFPdx9C PwN5B3ZDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4hGjk3 RBsCFDQpVUQeDz80
KABuAXdUEkELel07 IF4sX05QKwUVFgpV GEUl
X-Authentic-SMTP: 61633532353630.1020:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1U4rRe-0002lh-74
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
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: Mon, 11 Feb 2013 11:21:15 -0000
--ibTvN161/egqYuK8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Feb 09, 2013 at 03:33:25PM +0100, Timo Hanke wrote:
> > Why don't you use namecoin or another alt-chain for this?
>=20
> 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.
In what way are you not solving the same problem as DNS? I don't mean
the Luke-Jr's (quite correct) technical point about key-value maps, I
mean the human problem that I have these unique numbers that I can't
memorize, and I have some non-unique names that I can.
By creating Yet Another Totally Different System you are just creating
another way that users can be confused into thinking some name snatched
up by some scammers in some little-used PKI system is who they are
supposed to be communicating with. Fortunately your PKI system isn't
actually used and probably never will be, so it's not a big deal yet,
but ultimately you are adding to the problem.
Go work on namecoin and make it more usable. Then add some PKI to it
using the *same* domain names so when I see a PKI certificate for "foo"
I know it must be the same "foo" website I just visited and the same
"foo@foo" I just emailed.
> 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.
Alt-chains don't have to be based on mining you know. Your proof-of-work
can be replaced by proof-of-sacrifice, specifically Bitcoins. A
particularly nice scheme is to use transaction fees and Bitcoin block
height. Specifically every block in your alt-chain will have a merkle
path to a transaction in a Bitcoin block. Of course there can be more
than one such block, so you introduce a tie-breaker rule: the
transaction with the highest mining fee wins.
The reason why this is nice is because it becomes really easy to be sure
that a better chain won't turn up after the fact - make sure the
transaction linking the alt-chain to the Bitcoin block has the highest
fee in the block. Thus if you want to, say, register a domain name, do
so in the alt-chain, then "mine" the block by creating a suitable
transaction. Make sure it's the biggest fee, wait a few confirmations,
and you're good to go with the same level of security as Bitcoin proper.
Because the rule is that a merkle *path* exists, multiple alt-chains can
use this mechanism at the same time, with the exact same security
guarantee re: max fees. (note that you're chain needs to store copies of
the txin's for the tx sacrificing the fee, transactions by themselves do
not prove fees) Multiple parties can also colaborate to create the
transaction, each providing, and signing for, an input for their portion
of the total fee.
There is the problem that miners get to keep the fee, thus they can
create these special proof-of-sacrifice transactions at low cost, and
potentially make it difficult to get a block mined, or to be sure a
block won't be undone later. This problem can be solved with my
"two-step sacrifice" protocol.(1) Essentially you create a transaction
that is invalid until some time in the future and sacrifices Bitcoins to
mining fees, then create a second transaction that includes the first
one as data. You publish the second in the block chain, proving the
whole world had an opportunity to mine it. Eventually the first is in
fact mined, thus sacrificing Bitcoins to a miner you have no control
over. For a alt-chain you would consider the sacrifice to be a "balance"
and then spend that balance as required in later blocks in a way that is
guaranteed to be public so you can still check the security guarantee of
knowing your tx had the max fee. For instance with the contract protocol
I describe in (1), shave off what ever percentage of the original
sacrifice, linking the merkle-root of the merkel tree of alt-chains at
the same time. Anyone can still monitor the set of all two-step
sacrifices and associated contract movements and check that their one in
a block was the largest possible. Finally if you want to be nice, modify
the contract value rules so only the successful max contract value tx
has it's balance decreased.
1) https://github.com/petertodd/trustbits/blob/master/fidelitybond.md
Actually, you know gmaxwell, the above would be a great way to run the
alt-chain I'm probably going to need for the fraud proofs in Trustbits.
Although it does have the minor problem of being ludicrously complex...
> > 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.
>=20
> 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.=20
The blockchain grows at a maximum rate of 55GiB/year. Do you think your
users will all want to have that available just to validate some PKI
certificates?
--=20
'peter'[:-1]@petertodd.org
--ibTvN161/egqYuK8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBAgAGBQJRGNQeAAoJEH+rEUJn5PoE2jIH/1+blyGxOKRRFgwTl0d/ku+X
TnMrTozlbXdiFcjO/AvDnNMF5iOSm9sahoQV4wTP/aqQ833DaIru0uzKNKJDAmmS
1Qg35k8uUMJD4t/kviOVFzO+jBl1+/L3Hmmsr0t2EBue02Ln01860k/Ounu2cR3N
b0GXvwYQzbiVPjgHkKUfIp/PVBlZnVhNkWzMthoiED52JnpLIEs4ZxPQChsw/hxp
3JR5l8kaNqZhFK13QtNPX0LbD83+Bm5H+dTKlY8tedGMQig6GbxP7co0tOj2cVW6
QjzS7VhS6lMOjc3cBA9LHzgpQnxyiySJPFcHuqzWYiKa6KAhe8TfhzAL+0e2osA=
=nMl8
-----END PGP SIGNATURE-----
--ibTvN161/egqYuK8--
|
