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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mark@monetize.io>) id 1Vu512-0005lJ-D3
for bitcoin-development@lists.sourceforge.net;
Fri, 20 Dec 2013 18:41:40 +0000
Received: from mail-pd0-f175.google.com ([209.85.192.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Vu511-00081Q-1X
for bitcoin-development@lists.sourceforge.net;
Fri, 20 Dec 2013 18:41:40 +0000
Received: by mail-pd0-f175.google.com with SMTP id w10so2837785pde.6
for <bitcoin-development@lists.sourceforge.net>;
Fri, 20 Dec 2013 10:41:33 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:organization:user-agent
:mime-version:to:cc:subject:references:in-reply-to:content-type
:content-transfer-encoding;
bh=wwiEHQVM7TLpNOOg6VyfsSq2qa4rJQmWq6LzV/JUzUs=;
b=Mah23NJVAhhsoRy5NAHZ6Kbu5R51l4OaxGPLTJdNvKxuF7jzC7GVVJjXbLIm+Kg05d
sVezBGK84hWxhnslPbjhAnkocRD/HQ3VLCOqioGz/u9ePdqyGQRoBwBhkLpoYQ+grGqO
o+94QKjJV5kbl3n+r/BUfeqOoJWeP+mtVjhajSs6qgPnb+wYl9ktSg742iwde5UjtNdY
LTOhgPE4MgUhhL1NCoWU48NaxdUfT/7NK/Rzjbx0eBC8SLNKD/l+o9X2xxcqA0TnDZZn
C0jKBGxmI7ABYTY5qa5Z57MOCW43mtrur86LPr0vc4Mu+Sm0YLPDQ/yorZwawKbULwqo
yBMA==
X-Gm-Message-State: ALoCoQn2mUBrOLoNZAL1MPNalvRsv4hqhhaqx8Xz1tSJLtYyXAxSI1Mj0QarmsAOCt/LuCxyI1j2
X-Received: by 10.68.230.228 with SMTP id tb4mr10393462pbc.108.1387564893071;
Fri, 20 Dec 2013 10:41:33 -0800 (PST)
Received: from [192.168.127.182] (adsl-71-131-181-126.dsl.sntc01.pacbell.net.
[71.131.181.126])
by mx.google.com with ESMTPSA id ki1sm16120805pbd.1.2013.12.20.10.41.31
for <multiple recipients>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Fri, 20 Dec 2013 10:41:32 -0800 (PST)
Message-ID: <52B48F5B.8020706@monetize.io>
Date: Fri, 20 Dec 2013 10:41:31 -0800
From: Mark Friedenbach <mark@monetize.io>
Organization: Monetize.io Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Peter Todd <pete@petertodd.org>
References: <52B3A1C8.5000005@monetize.io>
<op.w8do7rg9yldrnw@laptop-air.hsd1.ca.comcast.net>
<52B42842.6000306@monetize.io> <20131220131731.GC21148@savin>
In-Reply-To: <20131220131731.GC21148@savin>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [209.85.192.175 listed in list.dnswl.org]
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: enigmail.net]
X-Headers-End: 1Vu511-00081Q-1X
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] BIP proposal: Authenticated prefix trees
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, 20 Dec 2013 18:41:40 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
(Sorry Peter, this was meant for the whole list:)
On 12/20/2013 05:17 AM, Peter Todd wrote:
> I've thought about this for awhile and come to the conclusion that
> UTXO commitments are a really bad idea. I myself wanted to see them
> implemented about a year ago for fidelity bonded banks, but I've
> changed my mind and I hope you do too.
>
> They force miners and every full node with SPV clients to store the
> entire UTXO set in perpetuity.
This is incorrect. If the slower proof-updatable hashes are used, then
mining only requires what I've called "operational proofs" to be
attached to received transactions and blocks.
Access to the UTXO set is required to make new transactions, at least
for the outputs of the transaction, but I do not believe this is as
significant a problem as you do. It is a service that can be
outsourced for a minimal fee - include an explicit output of the
necessary amount to a scriptPubKey specified by the archival node, and
they will make sure the proper proofs are attached.
> This is bad by itself, but then they make it even worse by making
> Bitcoin really useful and convenient to use as a decentralized
> database; UTXO commitments make it easy and convenient to
> implement systems like Namecoin on top of Bitcoin, yet we don't
> have the UTXO expiration that might make such uses reasonable.
> Right now the UTXO set is reasonable small - ~300MB - but that can
> and will change if we make it an attractive way to store data.
> UTXO commitments do exactly that.
You might have to explain this to me, but it is not clear to me how
the validation index could be twisted into providing a Namecoin-like
system. Or the address index either, which I presume is what you are
referring to. Namecoin works by assigning domains to outputs, and then
tracking ownership and configuration of that domain through chains of
outputs. But the UTXO set doesn't contain connecting information. At
best all it would be is a glorified, and expensive time-stamper,
unattractive because there are already better solutions.
> You're also *not* giving users what they actually want: the
> transactions associated with their wallets. Even though Electrum
> could easily work via a pure UTXO database they implemented
> transaction lookup instead; Electrum servers cough up every
> transaction associated with a user's wallet. If you're going to do
> that, it's just as easy to do per-block lookup trees which don't
> force the UTXO set to be stored.
At the cost of having the supposedly lightweight client query for each
of its coins on every single block, to construct a negative
proof-of-spend.
> There's also a more subtle issue: the security model of UTXO
> commitments sucks. It encourages wallets to essentially trust
> single confirmations because it's unlikely that nodes will want to
> store the multiple copies of the UTXO set required to provide
> proof of multiple confirmations. Basically the issue is when you
> start your wallet you get a proof of UTXO set for the most recent
> block; that's just one confirmation. To get more confirmations you
> have to wait for subsequent blocks, checking the set on each block.
> Per block indexes on the other hand naturally lead wallets to
> count confirmations properly.
I don't think this is true, or at least you are not considering
available optimizations. You certainly don't need to store multiple
copies of the UTXO set.
I'm a little confused as to the exact situation you are describing.
When a key is loaded into a wallet, or a wallet comes online after a
significant absence, it looks for coins in the current UTXO set. If
any coins are found, their attached transaction record has a block
height field, so the confirmation count can be derived from that. As
blocks go by that count is naturally increased. I'm not sure how this
is different from the current situation.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJStI9aAAoJEAdzVfsmodw4IooP/1uK9cvP1vxXyQRbAHf9oFXw
AmZ8p1+t8f6MHUpjkv/Xn0poFNU8qSnNz65drQdq8ErcJnqe4V3Wt6G32/uCxvZs
6AX6bRYQIfhHY0DBPgfacO5/ALdlnS4NdjWFCA5hHDgLd30BpbU1WK1ze985TXrd
+ucQkzcMYEDW2lb+sFvfhpi9ZPFd34ZrNzH//oS794eYKWAmj7jXqdgxk5AKat61
Xileq5beE4xom3pChXc3PtIJKsoil5SjE20/FW52wcCdyaEFG0kwl937pEGjQnlP
mylK/ilfZ6cvRC8MmVnl/6AC4V2hjB4Ncej03jG3JI2FdaJEOHuHg0uh8/Zl1I4A
YVIKyrHQhQb/VGsfXtW3zokHzDeEtJwlx+PPFaLc9QurFirNjSnenhbw4Vpbg3Xt
dH1Qd9xWcT85a19Oz8Q4rt3z7UmX9J/geZrUHCuPtr47yXU0e1Cc6ZP9zDYNtfKU
q6MjNZiaLJ/Wp0n4IeQ/4/wqy0rM/psP9i5d6IdP96tayVM9aKj5Lh9lU/Od5wGO
2PPB4kvhJfMbx3o+S7UK5vra7ysZzULpoVGDpUR3xRM72l//vlNhSLK5nILVO3r8
sIC5+3WoZLUKvuNo45/BDxXHZajrWLCU84WrwHVm1u7SHfBQcoES/rhcx2zlgyx0
/Iwxsgb7Fznl+eM2bEpZ
=TtaV
-----END PGP SIGNATURE-----
|
