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
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
|
Return-Path: <earonesty@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1DD7C40C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Aug 2017 17:24:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr0-f171.google.com (mail-wr0-f171.google.com
[209.85.128.171])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A85B840A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Aug 2017 17:24:11 +0000 (UTC)
Received: by mail-wr0-f171.google.com with SMTP id p8so40794230wrf.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Aug 2017 10:24:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to:cc;
bh=mP9KJrsW5DxjTNb/PPh5OIpbdEVc2PLM4oj2pQ0ReTk=;
b=csOrPlzgEZIGeB7bL9aHtkLDHQO3zplTTycgGPHIDZzIQ6sJjt9GNjH2Rs7fYd8r23
FuhgyR0HgYwHtTHxHEyOGYTTihYZ8gOq0OYC4lmgPnB1dfV4CI+A43W4RWdAORJLBb2e
J4tXGZj5Q8BYwjEfOO4KXToCYykeI7So4YsHm6zNTXt0Nc08gMSC9KqlAbWIo0ZwFN/x
63S4hQu+owmbkU8j+i3zicivBBfy9M0PrAlr0SjdZdAh0DSugKT2FsSEg7W8+oCFjvKD
CcgKSXfbm12ybX/e7QpOOnIiDPJcY0blDGM60l5LM8vKDf8CqDal8lu+iyEzHF6cAcJS
qc6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to:cc;
bh=mP9KJrsW5DxjTNb/PPh5OIpbdEVc2PLM4oj2pQ0ReTk=;
b=IOJQQpfK9eZtieoGDRXlJWLA+CxQQl2AZ/E+LqzE1X60H/Sffp6ci03hE8AQfWQWze
eY9qVCMmGvWHo/cn0BoQUBC6TsU7GI6i5GarEQ+QDelHOZfFVko51YPZM38tWvCZRAop
7KNkjUgqwng0aqxjUxLgQKJ3mT/JZxKYZ60hbMESBsXFZnld8kuz0mkWsBXgzPrHUFbP
o1w1yMBWWtKTsXYjGn75UQdjqCFTvcNx12/KEwM2d6eEMc99CM0/6HYJ4kKkje95X1S5
kIDnjUeInVH4BVTHQeyP7VejnNEdsM9BITLs10vrliIMhURsu4BmMHSh6Pa9LfvBihq1
0T+Q==
X-Gm-Message-State: AHYfb5jogjWPaqIGduHUwgbjPp6YQztpWqrStlN1+MhR0Lwjm6I/8XRn
XAROivISW+GT34NPG4OjAQc9cz1zzw==
X-Received: by 10.223.134.139 with SMTP id 11mr3119730wrx.255.1503336250171;
Mon, 21 Aug 2017 10:24:10 -0700 (PDT)
MIME-Version: 1.0
Sender: earonesty@gmail.com
Received: by 10.28.225.135 with HTTP; Mon, 21 Aug 2017 10:24:09 -0700 (PDT)
In-Reply-To: <CACiOHGwdNb=R95mE=UJOynKBtOc43Cxbjff8uZ4qakLMNX=Lbw@mail.gmail.com>
References: <CAAU88OoR7U3-hg9Mbf6iNB2V-V5Omd1y2UP7hwouc0jbwPPqgg@mail.gmail.com>
<CAGCathzWMVsmM1wO8eYAZmytEy1Q--ajdr0ssQHedaJWEPu0PA@mail.gmail.com>
<6e774a20-38f6-3932-4050-789c34f0c2b2@aei.ca>
<CACiOHGwdNb=R95mE=UJOynKBtOc43Cxbjff8uZ4qakLMNX=Lbw@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Mon, 21 Aug 2017 13:24:09 -0400
X-Google-Sender-Auth: 2rxEpf2KfLVr_rUNJP9kIRTaBbY
Message-ID: <CAJowKgKweWPjVC-Z5AeFA+47TL4Jdiub5ZLvSghLgCvnbSwHOg@mail.gmail.com>
To: Moral Agent <ethan.scruples@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a1146c4222b6640055746bff4"
X-Mailman-Approved-At: Mon, 21 Aug 2017 17:49:16 +0000
Cc: Major Kusanagi <majorkusanagibtc@gmail.com>
Subject: Re: [bitcoin-dev] UTXO growth scaling solution proposal
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Mon, 21 Aug 2017 17:24:12 -0000
--001a1146c4222b6640055746bff4
Content-Type: text/plain; charset="UTF-8"
1. If it only affects "old dust" UTXO's where the # of coins in the UTXO
aren't sufficient to pay some lower quantile of transaction fees, then
there can be little argument of theft or loss.
2. There's another use-case for demurrage as well.
Computation power may grow rapidly if quantum computing becomes more
common. At some point, Bitcoin may have to change the public key format
for coins and the POW used.
In order to do this, old coins will have to transact on the network, moving
their value to a new format, with many more bits in the public key, for
example. But since quantum computing isn't bounded by moore's law, so
this may need to be a regular upgrade every X years. Rather than a
regular "bit widening hard fork", the number of bits needed in a public
address format could be scaled to the difficulty of the new quantum hashing
algorithm that *also must *now grow in the # of bits over time. To ensure
that coins are secure, those with too few bits must drop off the network.
So the timing for old coin demurrage can effectively be based on the
quantum POW difficulty adjustments. As long as the subsequent exponential
rate of computation increase can be reasonably predicted (quantum version
of moore's law), the new rate of decay can be pegged to a number of years.
On Mon, Aug 21, 2017 at 10:26 AM, Moral Agent via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> A more forgiving option would be to have coins past a certain age
> evaporate into mining rewards at some rate, rather than all at once. People
> might find this approach easier to stomach as it avoids the "I waited 1
> block to many and all of my coins vanished" scenario.
>
> Another approach would to demand that a certain minimum mining fee be
> included that is calculated based on the age of an input like this idea:
> https://www.reddit.com/r/Bitcoin/comments/35ilir/
> prioritizing_utxos_using_a_minimum_mining_fee/
>
> This would result in the coins continuing to exist but not being
> economically spendable, and therefore the UTXO information could be
> archived.
>
> On Mon, Aug 21, 2017 at 9:35 AM, Thomas Guyot-Sionnest via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On 21/07/17 03:59 PM, Lucas Clemente Vella via bitcoin-dev wrote:
>> > 2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev
>> > <bitcoin-dev@lists.linuxfoundation.org
>> > <mailto:bitcoin-dev@lists.linuxfoundation.org>>:
>> >
>> > [...] But the fact is that if we want to make bitcoins last forever,
>> > we have the accept unbounded UTXO growth, which is unscalable. So
>> > the only solution is to limit UTXO growth, meaning bitcoins cannot
>> > last forever. This proposed solution however does not prevent
>> > Bitcoin from lasting forever.
>> >
>> >
>> > Unless there is a logical contradiction in this phrasing, the proposed
>> > solution does not improves scalability:
>> > - "Bitcoins lasting forever" implies "unscalable";
>> > - "not prevent Bitcoin from lasting forever" implies "Bitcoins lasting
>> > forever";
>> > - Thus: "not prevent Bitcoin from lasting forever" implies
>> "unscalable".
>> >
>> > In practice, the only Bitcoin lost would be those whose owners forgot
>> > about or has lost the keys, because everyone with a significant amount
>> > of Bitcoins would always shift them around before it loses any luster (I
>> > wouldn't bother to move my Bitcoins every 10 years). I don't know how to
>> > estimate the percentage of UTXO is actually lost/forgotten, but I have
>> > the opinion it isn't worth the hassle.
>> >
>> > As a side note, your estimate talks about block size, which is
>> > determines blockchain size, which can be "safely" pruned (if you are not
>> > considering new nodes might want to join the network, in case the full
>> > history is needed to be stored somewhere). But UTXO size, albeit related
>> > to the full blockchain size, is the part that currently can not be
>> > safely pruned, so I don't see the relevance of the analysis.
>>
>> I think if we wanted to burn lost/stale coins a better approach would be
>> returning them to miner's as a fee - there will always be lost coins and
>> miners will be able to get that additional revenue stream as the mining
>> reward halves. I also don't think we need to worry about doing a gradual
>> value loss neither, we should just put a limit on UTXO age in block
>> count (actually I would round it up to 210k blocks as explained below...).
>>
>>
>> So lets say for example we decide to keep 5 210k blocks "generations"
>> (that's over 15 years), then on the first block of the 6th generation
>> all UTXO's from the 1st generation are invalidated and returned into a
>> "pool".
>>
>> Given these (values in satoshis):
>>
>> Pool "P" (invalided UTXO minus total value reclaimed since last halving)
>> Leftover blocks "B" (210,000 minus blocks mined since last halving)
>>
>> Then every mined block can reclaim FLOOR(P/B) satoshi in addition to
>> miner's reward and tx fees.
>>
>> If the last block of a generation does not get the remainder of the pool
>> (FLOOR(P/1) == P) it should get carried over.
>>
>>
>> This would ensure we can clear old blocks after a few generations and
>> that burnt/lost coins eventually get back in circulation. Also it would
>> reduce the reliance of miners on actual TX fees.
>>
>>
>> To avoid excessive miner reward initially, for the first few iterations
>> the value of B could be increased (I haven't calculated the UTXO size of
>> the first 210k blocks but it could be excessively high...) or the value
>> each block can reclaim could be caped (so we would reclaim at an
>> artificial capacity until the pool depletes...).
>>
>>
>> Regards,
>>
>> --
>> Thomas
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a1146c4222b6640055746bff4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>1. If it only affects "old dust" UTXO's=
where the # of coins in the UTXO aren't sufficient to pay some lower q=
uantile of transaction fees, then there can be little argument of theft or =
loss.<br><br></div><div>2. There's another use-case for demurrage as we=
ll.<br></div><div><br>Computation power may grow rapidly if quantum computi=
ng becomes more common.=C2=A0 At some point, Bitcoin may have to change the=
public key format for coins and the POW used.<br><br>In order to do this, =
old coins will have to transact on the network, moving their value to a new=
format, with many more bits in the public key, for example.=C2=A0=C2=A0 Bu=
t since quantum computing isn't bounded by moore's law, so this may=
need to be a regular upgrade every X years.=C2=A0=C2=A0 Rather than a regu=
lar "bit widening hard fork", the number of bits needed in a publ=
ic address format could be scaled to the difficulty of the new quantum hash=
ing algorithm that <i>also must </i>now grow in the # of bits over time.=C2=
=A0=C2=A0 To ensure that coins are secure, those with too few bits must dro=
p off the network.=C2=A0=C2=A0 So the timing for old coin demurrage can eff=
ectively be based on the quantum POW difficulty adjustments.=C2=A0=C2=A0 As=
long as the subsequent exponential rate of computation increase can be rea=
sonably predicted (quantum version of moore's law), the new rate of dec=
ay can be pegged to a number of years.<br><br></div><div></div><br></div><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Aug 21, 201=
7 at 10:26 AM, Moral Agent via bitcoin-dev <span dir=3D"ltr"><<a href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-de=
v@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr">A more forgiving option would be to have coins pa=
st a certain age evaporate into mining rewards at some rate, rather than al=
l at once. People might find this approach easier to stomach as it avoids t=
he "I waited 1 block to many and all of my coins vanished" scenar=
io.<div><br></div><div>Another approach would to demand that a certain mini=
mum mining fee be included that is calculated based on the age of an input =
like this idea: <a href=3D"https://www.reddit.com/r/Bitcoin/comments/35ilir=
/prioritizing_utxos_using_a_minimum_mining_fee/" target=3D"_blank">https://=
www.reddit.com/r/<wbr>Bitcoin/comments/35ilir/<wbr>prioritizing_utxos_using=
_a_<wbr>minimum_mining_fee/</a></div><div><br></div><div>This would result =
in the coins continuing to exist but not being economically spendable, and =
therefore the UTXO information could be archived.</div></div><div class=3D"=
HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmai=
l_quote">On Mon, Aug 21, 2017 at 9:35 AM, Thomas Guyot-Sionnest via bitcoin=
-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 21/07/17 03:59 =
PM, Lucas Clemente Vella via bitcoin-dev wrote:<br>
> 2017-07-21 16:28 GMT-03:00 Major Kusanagi via bitcoin-dev<br>
> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a><br>
</span>> <mailto:<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.=
org" target=3D"_blank">bitcoin-dev@lists.linu<wbr>xfoundation.org</a>>&g=
t;:<br>
<span>><br>
>=C2=A0 =C2=A0 =C2=A0[...] But the fact is that if we want to make bitco=
ins last forever,<br>
>=C2=A0 =C2=A0 =C2=A0we have the accept unbounded UTXO growth, which is =
unscalable. So<br>
>=C2=A0 =C2=A0 =C2=A0the only solution is to limit UTXO growth, meaning =
bitcoins cannot<br>
>=C2=A0 =C2=A0 =C2=A0last forever. This proposed solution however does n=
ot prevent<br>
>=C2=A0 =C2=A0 =C2=A0Bitcoin from lasting forever.<br>
><br>
><br>
> Unless there is a logical contradiction in this phrasing, the proposed=
<br>
> solution does not improves scalability:<br>
>=C2=A0 - "Bitcoins lasting forever" implies "unscalable&=
quot;;<br>
>=C2=A0 - "not prevent Bitcoin from lasting forever" implies &=
quot;Bitcoins lasting<br>
> forever";<br>
>=C2=A0 - Thus: "not prevent Bitcoin from lasting forever" imp=
lies "unscalable".<br>
><br>
> In practice, the only Bitcoin lost would be those whose owners forgot<=
br>
> about or has lost the keys, because everyone with a significant amount=
<br>
> of Bitcoins would always shift them around before it loses any luster =
(I<br>
> wouldn't bother to move my Bitcoins every 10 years). I don't k=
now how to<br>
> estimate the percentage of UTXO is actually lost/forgotten, but I have=
<br>
> the opinion it isn't worth the hassle.<br>
><br>
> As a side note, your estimate talks about block size, which is<br>
> determines blockchain size, which can be "safely" pruned (if=
you are not<br>
> considering new nodes might want to join the network, in case the full=
<br>
> history is needed to be stored somewhere). But UTXO size, albeit relat=
ed<br>
> to the full blockchain size, is the part that currently can not be<br>
> safely pruned, so I don't see the relevance of the analysis.<br>
<br>
</span>I think if we wanted to burn lost/stale coins a better approach woul=
d be<br>
returning them to miner's as a fee - there will always be lost coins an=
d<br>
miners will be able to get that additional revenue stream as the mining<br>
reward halves. I also don't think we need to worry about doing a gradua=
l<br>
value loss neither, we should just put a limit on UTXO age in block<br>
count (actually I would round it up to 210k blocks as explained below...).<=
br>
<br>
<br>
So lets say for example we decide to keep 5 210k blocks "generations&q=
uot;<br>
(that's over 15 years), then on the first block of the 6th generation<b=
r>
all UTXO's from the 1st generation are invalidated and returned into a<=
br>
"pool".<br>
<br>
Given these (values in satoshis):<br>
<br>
Pool "P" (invalided UTXO minus total value reclaimed since last h=
alving)<br>
Leftover blocks "B" (210,000 minus blocks mined since last halvin=
g)<br>
<br>
Then every mined block can reclaim FLOOR(P/B) satoshi in addition to<br>
miner's reward and tx fees.<br>
<br>
If the last block of a generation does not get the remainder of the pool<br=
>
(FLOOR(P/1) =3D=3D P) it should get carried over.<br>
<br>
<br>
This would ensure we can clear old blocks after a few generations and<br>
that burnt/lost coins eventually get back in circulation. Also it would<br>
reduce the reliance of miners on actual TX fees.<br>
<br>
<br>
To avoid excessive miner reward initially, for the first few iterations<br>
the value of B could be increased (I haven't calculated the UTXO size o=
f<br>
the first 210k blocks but it could be excessively high...) or the value<br>
each block can reclaim could be caped (so we would reclaim at an<br>
artificial capacity until the pool depletes...).<br>
<br>
<br>
Regards,<br>
<br>
--<br>
Thomas<br>
<div class=3D"m_-400861160530479602HOEnZb"><div class=3D"m_-400861160530479=
602h5"><br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>
--001a1146c4222b6640055746bff4--
|
