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
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
|
Return-Path: <ricardojdfilipe@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 41A28C2C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 13 Dec 2015 21:20:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com
[209.85.213.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 158D4130
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 13 Dec 2015 21:20:22 +0000 (UTC)
Received: by mail-ig0-f172.google.com with SMTP id su19so71519456igc.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 13 Dec 2015 13:20:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=LwIJ4e8kgHGguH21Qc1+iRNa0XNkbEPC/BT4Xqo46CA=;
b=Homu3s2iHUNIiX7c+loYoymvoylA7qPBlpaJC4LyaJK3HFSo96Tg4NzIG8bV9Xaahn
0bS3RKiUS+nbyKD653/zeNFASj0Kw59caHHojDVvSRDrbUFQOFQa08zFZIbeWmiSMO/3
bSNcj0IMPsCNKEI+h87H7HveTYC5JEis1subJJKekVgd5eEct+xCOsfaJdckdPMoEt35
KGfaT55HI0qQy0AqKqNBgQtnN7sjvBXs9BnnaIPsTXK5o1uKy5Ve958RAXC8XZdZV7Au
PYhVR+pkP0oS3Tb0bSGsWDy3NKK6949sd/1WUrfjG8Il1lE55JZnakuA9zO8kQJs09u5
OZ2g==
MIME-Version: 1.0
X-Received: by 10.50.155.106 with SMTP id vv10mr13573413igb.36.1450041621461;
Sun, 13 Dec 2015 13:20:21 -0800 (PST)
Received: by 10.36.28.79 with HTTP; Sun, 13 Dec 2015 13:20:21 -0800 (PST)
In-Reply-To: <3b28f994d75070ab1fd2d312f29bb706@xbt.hk>
References: <50e629572d8de852eb789d50b34da308@xbt.hk>
<1449961269.2210.5.camel@yahoo.com>
<CACrzPenXGQZBrx8QC+1QE2oCE3N=qmfgc_OWrowtjtLjGkZrRA@mail.gmail.com>
<CAAS2fgQi7aiwyOaVBiMbp6t9D58aFAmDdKPzFiscB6ouGzBK6A@mail.gmail.com>
<CAAcC9yuSX67ckhBUCsvTk+7PB6vzufuuBsJikSqqqU_4LXoCfA@mail.gmail.com>
<CAAS2fgSchJFk1Ejd8ZfMSzxEO-1TWYR6ag-seQNH_QHrc9Cn3w@mail.gmail.com>
<CAAcC9ysovzcm1SD_4XyxxofmwdXrcQqs0ckQBw626vYsdPftKw@mail.gmail.com>
<3b28f994d75070ab1fd2d312f29bb706@xbt.hk>
Date: Sun, 13 Dec 2015 21:20:21 +0000
Message-ID: <CALC81CPN7WmF8sd8jkP7hzPdzzWL6K0SVWpUiXW7dEPpX0DdzA@mail.gmail.com>
From: Ricardo Filipe <ricardojdfilipe@gmail.com>
To: jl2012@xbt.hk
Content-Type: multipart/alternative; boundary=001a11346b48c1d7d30526ce1fea
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 16 Dec 2015 02:17:36 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin
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, 13 Dec 2015 21:20:23 -0000
--001a11346b48c1d7d30526ce1fea
Content-Type: text/plain; charset=UTF-8
I really like ideas that tackle this issue. The question imho is what is
the incentive to run a "Full UTXO node" instead of a pruned or archive node.
For starters, it would be nice to know what would be the savings for Full
UTXO nodes over archive nodes right now.
Also, what advantages would this have over "archive pruned nodes: nodes
that store X blocks of the whole blockchain before 420000". Seems like an
interesting intermediate use case to me too.
2015-12-13 18:11 GMT+00:00 jl2012--- via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Mon, Dec 14, 2015 at 12:14 AM, Danny Thorpe <danny.thorpe@gmail.com>
> wrote:
>
>> What is the current behavior / cost that this proposal is trying to
>> avoid? Are ancient utxos required to be kept in memory always in a fully
>> validating node, or can ancient utxos get pushed out of memory like a
>> normal LRU caching db?
>>
>
> I don't see why it must be kept in memory. But storage is still a problem.
> With the 8 year limit and a fixed max block size, it indirectly sets an
> upper limit for UTXO set.
>
>
> Chris Priest via bitcoin-dev :
>
>> This isn't going to kill bitcoin, but it won't make it any better.
>>
>
> Do you believe that thousands of volunteer full nodes are obliged to store
> an UTXO record, just because one paid US$0.01 to an anonymous miner 100
> years ago? It sounds insanely cheap, isn't it? My proposal (or similar
> proposal by Peter Todd) is to solve this problem. Many commercial banks
> have a dormant threshold less than 8 years so I believe it is a balanced
> choice.
>
> Back to the topic, I would like to further elaborate my proposal.
>
> We have 3 types of full nodes:
>
> Archive nodes: full nodes that store the whole blockchain
> Full UTXO nodes: full nodes that fully store the latest UTXO state, but
> not the raw blockchain
> Lite UTXO nodes: full nodes that store only UTXO created in that past
> 420000 blocks
>
> Currently, if one holds nothing but a private key, he must consult either
> an archive node or a full UTXO node for the latest UTXO state to spend his
> coin. We currently do not have any lite UTXO node, and such node would not
> work properly beyond block 420000.
>
> With the softfork I described in my original post, if the UTXO is created
> within the last 420000 blocks, the key holder may consult any type of full
> node, including a lite UTXO node, to create the transaction.
>
> If the UTXO has been confirmed by more than 420000 blocks, a lite UTXO
> node obviously can't provide the necessary information to spend the coin.
> However, not even a full UTXO node may do so. A full UTXO node could tell
> the position of the UTXO in the blockchain, but can't provide all the
> information required by my specification. Only an archive node may do so.
>
> What extra information is needed?
>
> (1) If your UTXO was generated in block Y, you first need to know the TXO
> state (spent / unspent) of all outputs in block Y at block (Y + 420000).
> Only UTXOs at that time are relevant.
>
> (2) You also need to know if there was any spending of any block Y UTXOs
> after block (Y + 420000).
>
> It is not possible to construct the membership prove I require without
> these information. It is designed this way, so that lite UTXO nodes won't
> need to store any dormant UTXO records: not even the hash of individual
> dormant UTXO records. If the blockchain grows to insanely big, it may take
> days or weeks to retrieve to records. However, I don't think this is
> relevant as one has already left his coins dormant for >8 years. Actually,
> you don't even need the full blockchain. For (1), all you need is the
> 420000 blocks from Y to Y+420000 minus any witness data, as you don't need
> to do any validation. For (2), you just need the coinbase of Y+420001 to
> present, where any spending would have been committed, and retrieve the
> full block only if a spending is found.
>
> So the Bitcoin Bank (miners) is not going to shred your record and
> confiscate your money. Instead, the Bank throws your record to the garage
> (raw blockchain). You can search for your record by yourself, or employ
> someone (archive node) to search it for you. In any case it incurs costs.
> But as thousands of bankers have kept your record on their limited desk
> space for 8 years for free (though one of them might receive a fraction of
> a penny from you), you shouldn't complain with any moral, technical, or
> legal reason. And no matter what users say, I believe something like this
> will happen when miners and full nodes can't handle the UTXO set.
>
> I'd like to see more efficient proposals that archive the same goals.
>
> p.s. there were some typos in my original. The second sentence of the
> second paragraph should be read as "For every block X+420000, it will
> commit to a hash for all UTXOs generated in block X."
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQGcBAEBCAAGBQJWbbR2AAoJEO6eVSA0viTScEoL/RPlsxr0A5wTtgdi+9i4AFlV
> Sw/He89+YPGe5VCG74YNAPLEUF1/rICzUJ4DulvNTOo/5xtmkv5ok4bD7v1JZnH3
> DE2PExMQYs2X4Qm6mkcwi8IWlMR2U5j5ebUq21Kj4AqVFj9UcQmYGhPehB2f+cM9
> Wki/TDwNj5fV8AZ4uR9pPgaf+bvVQQ9BOOLiIMiTbphNCx1hfGfYcsqmXlCbGk9A
> PatGR88aQTxpa7PhbCZwwf76cKuOaYYZeHr9jRR9RL5rZVXgE1SI/niBytJhXaP8
> lwYtk4Bpz0IGd23v1dArNQQoOp5Xycbeq1l1qyv/qtxju65No+dhqiEcFBZVI1AS
> VcndMQ+yvNuxVgib2Ifh9YjXelWAqqLzzoVcz2RxXh6HJ0tVKxBokwdAcsclZb93
> zQ1JhDR4vBpLquytZA8lDIxJraNCdB/KEAOAey6ljP3zL7fBLBp1oZw4DDDtFy8V
> EMjrOSVnjyuyfey2YXsGnnHuQS0mpwmSroV2400uGQ==
> =2xRy
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a11346b48c1d7d30526ce1fea
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I really like ideas that tackle this issue. The question i=
mho is what is the incentive to run a "<span style=3D"color:rgb(0,0,0)=
;font-size:12.8px">Full UTXO node" instead of a pruned or archive node=
.</span><br style=3D"color:rgb(0,0,0);font-size:12.8px"><div><span style=3D=
"font-size:12.8px;color:rgb(0,0,0)">For starters, it would be nice to know =
what would be the savings for Full UTXO nodes over archive nodes right now.=
</span></div><div><span style=3D"font-size:12.8px;color:rgb(0,0,0)">Also, w=
hat advantages would this have over "archive pruned nodes: nodes that =
store X blocks of the whole blockchain before 420000". Seems like an i=
nteresting intermediate use case to me too.</span><br></div></div><div clas=
s=3D"gmail_extra"><br><div class=3D"gmail_quote">2015-12-13 18:11 GMT+00:00=
jl2012--- via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-=
dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfou=
ndation.org</a>></span>:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PG=
P SIGNED MESSAGE-----<br>
Hash: SHA256<span class=3D""><br>
<br>
On Mon, Dec 14, 2015 at 12:14 AM, Danny Thorpe <<a href=3D"mailto:danny.=
thorpe@gmail.com" target=3D"_blank">danny.thorpe@gmail.com</a>> wrote:<b=
r>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
What is the current behavior / cost that this proposal is trying to avoid? =
Are ancient utxos required to be kept in memory always in a fully validatin=
g node, or can ancient utxos get pushed out of memory like a normal LRU cac=
hing db?<br>
</blockquote>
<br></span>
I don't see why it must be kept in memory. But storage is still a probl=
em. With the 8 year limit and a fixed max block size, it indirectly sets an=
upper limit for UTXO set.<br>
<br>
<br>
Chris Priest via bitcoin-dev :<span class=3D""><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
This isn't going to kill bitcoin, but it won't make it any better.<=
br>
</blockquote>
<br></span>
Do you believe that thousands of volunteer full nodes are obliged to store =
an UTXO record, just because one paid US$0.01 to an anonymous miner 100 yea=
rs ago? It sounds insanely cheap, isn't it? My proposal (or similar pro=
posal by Peter Todd) is to solve this problem. Many commercial banks have a=
dormant threshold less than 8 years so I believe it is a balanced choice.<=
br>
<br>
Back to the topic, I would like to further elaborate my proposal.<br>
<br>
We have 3 types of full nodes:<br>
<br>
Archive nodes: full nodes that store the whole blockchain<br>
Full UTXO nodes: full nodes that fully store the latest UTXO state, but not=
the raw blockchain<br>
Lite UTXO nodes: full nodes that store only UTXO created in that past 42000=
0 blocks<br>
<br>
Currently, if one holds nothing but a private key, he must consult either a=
n archive node or a full UTXO node for the latest UTXO state to spend his c=
oin. We currently do not have any lite UTXO node, and such node would not w=
ork properly beyond block 420000.<br>
<br>
With the softfork I described in my original post, if the UTXO is created w=
ithin the last 420000 blocks, the key holder may consult any type of full n=
ode, including a lite UTXO node, to create the transaction.<br>
<br>
If the UTXO has been confirmed by more than 420000 blocks, a lite UTXO node=
obviously can't provide the necessary information to spend the coin. H=
owever, not even a full UTXO node may do so. A full UTXO node could tell th=
e position of the UTXO in the blockchain, but can't provide all the inf=
ormation required by my specification. Only an archive node may do so.<br>
<br>
What extra information is needed?<br>
<br>
(1) If your UTXO was generated in block Y, you first need to know the TXO s=
tate (spent / unspent) of all outputs in block Y at block (Y + 420000). Onl=
y UTXOs at that time are relevant.<br>
<br>
(2) You also need to know if there was any spending of any block Y UTXOs af=
ter block (Y + 420000).<br>
<br>
It is not possible to construct the membership prove I require without thes=
e information. It is designed this way, so that lite UTXO nodes won't n=
eed to store any dormant UTXO records: not even the hash of individual dorm=
ant UTXO records. If the blockchain grows to insanely big, it may take days=
or weeks to retrieve to records. However, I don't think this is releva=
nt as one has already left his coins dormant for >8 years. Actually, you=
don't even need the full blockchain. For (1), all you need is the 4200=
00 blocks from Y to Y+420000 minus any witness data, as you don't need =
to do any validation. For (2), you just need the coinbase of Y+420001 to pr=
esent, where any spending would have been committed, and retrieve the full =
block only if a spending is found.<br>
<br>
So the Bitcoin Bank (miners) is not going to shred your record and confisca=
te your money. Instead, the Bank throws your record to the garage (raw bloc=
kchain). You can search for your record by yourself, or employ someone (arc=
hive node) to search it for you. In any case it incurs costs. But as thousa=
nds of bankers have kept your record on their limited desk space for 8 year=
s for free (though one of them might receive a fraction of a penny from you=
), you shouldn't complain with any moral, technical, or legal reason. A=
nd no matter what users say, I believe something like this will happen when=
miners and full nodes can't handle the UTXO set.<br>
<br>
I'd like to see more efficient proposals that archive the same goals.<b=
r>
<br>
p.s. there were some typos in my original. The second sentence of the secon=
d paragraph should be read as "For every block X+420000, it will commi=
t to a hash for all UTXOs generated in block X."<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2<br>
<br>
iQGcBAEBCAAGBQJWbbR2AAoJEO6eVSA0viTScEoL/RPlsxr0A5wTtgdi+9i4AFlV<br>
Sw/He89+YPGe5VCG74YNAPLEUF1/rICzUJ4DulvNTOo/5xtmkv5ok4bD7v1JZnH3<br>
DE2PExMQYs2X4Qm6mkcwi8IWlMR2U5j5ebUq21Kj4AqVFj9UcQmYGhPehB2f+cM9<br>
Wki/TDwNj5fV8AZ4uR9pPgaf+bvVQQ9BOOLiIMiTbphNCx1hfGfYcsqmXlCbGk9A<br>
PatGR88aQTxpa7PhbCZwwf76cKuOaYYZeHr9jRR9RL5rZVXgE1SI/niBytJhXaP8<br>
lwYtk4Bpz0IGd23v1dArNQQoOp5Xycbeq1l1qyv/qtxju65No+dhqiEcFBZVI1AS<br>
VcndMQ+yvNuxVgib2Ifh9YjXelWAqqLzzoVcz2RxXh6HJ0tVKxBokwdAcsclZb93<br>
zQ1JhDR4vBpLquytZA8lDIxJraNCdB/KEAOAey6ljP3zL7fBLBp1oZw4DDDtFy8V<br>
EMjrOSVnjyuyfey2YXsGnnHuQS0mpwmSroV2400uGQ=3D=3D<br>
=3D2xRy<br>
-----END PGP SIGNATURE-----<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br></div>
--001a11346b48c1d7d30526ce1fea--
|