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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1U3lhs-0008PD-Io
for bitcoin-development@lists.sourceforge.net;
Fri, 08 Feb 2013 11:01:24 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.109 as permitted sender)
client-ip=62.13.148.109; envelope-from=pete@petertodd.org;
helo=outmail148109.authsmtp.co.uk;
Received: from outmail148109.authsmtp.co.uk ([62.13.148.109])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1U3lhp-0004vZ-VD for bitcoin-development@lists.sourceforge.net;
Fri, 08 Feb 2013 11:01:24 +0000
Received: from mail-c233.authsmtp.com (mail-c233.authsmtp.com [62.13.128.233])
by punt12.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
r18B1F6T089615; Fri, 8 Feb 2013 11:01:15 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 r18B1537031578
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Fri, 8 Feb 2013 11:01:08 GMT
Date: Fri, 8 Feb 2013 06:01:08 -0500
From: Peter Todd <pete@petertodd.org>
To: Timo Hanke <timo.hanke@web.de>
Message-ID: <20130208110108.GA6893@savin>
References: <20130208100354.GA26627@crunch>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c"
Content-Disposition: inline
In-Reply-To: <20130208100354.GA26627@crunch>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: d7816b0a-71de-11e2-a49c-0025907707a1
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdgoUHlAWAgsB AmUbWlVeUFx7WWs7 bAxPbAVDY01GQQRq
WVdMSlVNFUsqABRz BxsdVRlxdgBBcDBx ZkViVj4PW0x7cxR9
E1NTFDlTeGZhPWIC AURRJB5UcAFPdx9C bVB4BXJDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4hGjk3 RBsCFDQpVUQeDz80
KABuAXdUEkELel07 IF4sX05QKwUVFgpV GEUl
X-Authentic-SMTP: 61633532353630.1021: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: 1U3lhp-0004vZ-VD
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: Fri, 08 Feb 2013 11:01:24 -0000
--sm4nu43k4a2Rpi4c
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Feb 08, 2013 at 11:03:54AM +0100, Timo Hanke wrote:
> First, we have drafted a quite general specification for bitcoin certific=
ates (protobuf messages) that allow for a variety of payment protocols (e.g=
=2E 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.
>=20
> We have patched the bitcoind to handle certificates, submit signatures to=
the blockchain, verify certificates against the blockchain, pay directly t=
o certificates (with various payment methods), revoke certificates.
> Signatures in the blockchain are stored entirely in the UTXO set (i.e. th=
e unspend, unprunable outputs).=20
> This seems to make signature lookup and verification reasonably fast:=20
> 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?
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
=66rom 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.
In https://github.com/bcpki/bitcoin/wiki/Technical you say that you have
a minimum amount required for an outpoint to be valid, set at 0.05BTC.
That's a nice touch, and sort of works because this is a consensus
protocol, but if the exchange rate climbs significantly there will be a
lot of pressure to reduce that value. (setting minimum value by chain
height) What will happen then is there will be a mad rush to squat on
previously unaffordable domains, further disrupting Bitcoin's purpose as
a financial network.
In addition you'll also have a second problem: squatting of subsequent
transactions, particularly for valuable bcvalues. Basically if someone
already has "microsoft" insert bcvalues after their tx in case they
accidentally spend it. Of course, this will be done by people buying
bcvalues as well. Again, all this further clogs up the UTXO set.
I also can't figure out why you say signature lookup and verification
takes 10s - this should be an O(1) operation if you maintain a mapping
of candidate pubkeys to linked-lists of sorted applicable transactions.
Finally, why is this implemented within the reference client? Use the
raw transaction API and make up your own database. If you want, create a
RPC command that allows you to query the UTXO set directly; this would
be a useful feature to have. This patch will never be accepted to the
reference client, so you'll just wind up having to maintain a fork. Even
for a prototype this approach is ill-advised - prototypes have a bad way
of turning into production code.
In short, please don't do this.
--=20
'peter'[:-1]@petertodd.org
--sm4nu43k4a2Rpi4c
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBAgAGBQJRFNr0AAoJEH+rEUJn5PoE2x4IAIllbK1xPRtnVz0im0I23A/d
MJfT+df3PTUGvLq3gB9DFvYb+qowsxGJlkIf5+OTI2LW7TuTb0EqOcyJH8xlQNhO
tKwncqMh3Ow+sglTHfE2qwhJD2T/WkG5h1Gg7NewPB1IhZMwNUxPtI/My/O8iLH0
cSb0HZ0SjS0yWb+LLeb5nP+e/eoJuJzkrqI7y1U8IFnc1vkp7xN1ZeSDq/9GpVoC
ypO8troHNV/xTMQxEn0zvBf2ItaVE9GTR4k4fiETBJUPWncwdWRTeFIgqih6duMT
eSBN5ok3GxLLinbF+dRPJA2XFVkKHUHeWt+qiBEzLL5z/y5LervQjaCNAeX3054=
=B9I6
-----END PGP SIGNATURE-----
--sm4nu43k4a2Rpi4c--
|
