summaryrefslogtreecommitdiff
path: root/64/97295ab60aef9af081e7da7a774c3e8d32a134
blob: 9d992b415400df0e231036f80e4213463562bda0 (plain)
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
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
Return-Path: <earonesty@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id EE0FFC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 14 Jul 2022 16:01:56 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id C749741A01
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 14 Jul 2022 16:01:56 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org C749741A01
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=q32-com.20210112.gappssmtp.com
 header.i=@q32-com.20210112.gappssmtp.com header.a=rsa-sha256
 header.s=20210112 header.b=BviOH0zw
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=no autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id ct_KUQ7lfnAz
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 14 Jul 2022 16:01:55 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org BB228419F6
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com
 [IPv6:2a00:1450:4864:20::131])
 by smtp4.osuosl.org (Postfix) with ESMTPS id BB228419F6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 14 Jul 2022 16:01:54 +0000 (UTC)
Received: by mail-lf1-x131.google.com with SMTP id z25so3581156lfr.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 14 Jul 2022 09:01:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=q32-com.20210112.gappssmtp.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=edsbawlD1vcacefcO+/9IR6TzmP4H8vXajSW9Lwkvug=;
 b=BviOH0zwciylkp4JUHLD9LWGcxtps9sVM3e7AZlprinuCkDr5ZRr7sw3pfw9hpqi1Q
 J9bt4EP54IGbj80thwbU+l+dxG+DvKnh2JtpImbBtYx+yOxHx+n4EFin5+K4RQZ4nL/U
 C+MvK8i9p4AqY+HufetxmjssCQ3w67rR1k51Ks9TIlZ9WNvxrTY18OTqODty0qKx49V8
 RHuFgiCLnMdhJbKIFLER/glxV0sVvZDPkMmMCFTClxBPaTE+1s3rDAjjBZmUOvpDyxlc
 8gW2gNHjPiMH8zgZv2ZWBaf+fXuvQepQmtxN1N90pYqkgi5qrhuQm+r5j0GgsDcsF9Vi
 HAvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=edsbawlD1vcacefcO+/9IR6TzmP4H8vXajSW9Lwkvug=;
 b=2YfzTQ7AYgRU8d1JB6RWZLmcpRfatXCNaia/2isBNpCqKEI/7Vioqpz3DYE7EfgSe8
 3sv7jw6LS/vd6Kz+4z+0dCVjMhjvSB/Z08XlGA31tDh1keV24Xd56iQKycSslqtA5K76
 n86h4nCJ/vz+ULSz/D5ybDjykEYD5nrKpdIvGex4y5gJdqEY2kyOPsL3x6KQ9MfujpDT
 tCBOqkH7aroe5lnwjzl6b6XIBRpPFuFmoVOF+Q/Hhbdgj8af2bHx6T0pdB9unoD0VEUS
 9uo2kLlyzPwzC6NKmA9jmJojjzQJzO4CJgaO6TWdClCgmeIffCEEz9+7GlC7hyJkSjiG
 Y0nA==
X-Gm-Message-State: AJIora+shQ+UqtoXqX2FltuurkoYeGmRO9tXGJVh75S7A0+ow9LZ8QJg
 1ZhgevxFWzZZbou2/Qh664EUKbovMfXhKNWUU5spuMw=
X-Google-Smtp-Source: AGRyM1v6TGtPqSRXmZFcng0EXJ8gAhnH1oBESxqNWU3+0NYnPln9Qg6SZJNg81JngC4YgBVrzUQJSuOJrP3YQnjVcNM=
X-Received: by 2002:a05:6512:3ca2:b0:48a:7f7:3a20 with SMTP id
 h34-20020a0565123ca200b0048a07f73a20mr5616055lfv.153.1657814511636; Thu, 14
 Jul 2022 09:01:51 -0700 (PDT)
MIME-Version: 1.0
References: <CAAxiurZhzhPNuysoaByiLCdRpeyxz8S+onnoGTWC+MpanDFB_Q@mail.gmail.com>
 <164548764-bff50cb79078c9964aa8ac1e51c13070@pmq5v.m5r2.onet>
 <CAJowKgL3eg9aRxkbLiVUyMoMapFUnSBMpA1mnrxB=3fx1fsu0w@mail.gmail.com>
 <CAA3CggE4cJO_=8YR82qYOS=9PR34mSVsGznOuexTNpHbRuW6hw@mail.gmail.com>
In-Reply-To: <CAA3CggE4cJO_=8YR82qYOS=9PR34mSVsGznOuexTNpHbRuW6hw@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Thu, 14 Jul 2022 12:01:39 -0400
Message-ID: <CAJowKg+cYDK_r6-hXOxH83HCZhzQTMGUyhrx0+wk0aZCYH-C5w@mail.gmail.com>
To: Gino Pinuto <gino.pinuto@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000011d51305e3c605c3"
X-Mailman-Approved-At: Thu, 14 Jul 2022 16:34:03 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Security problems with relying on transaction
 fees for security
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Thu, 14 Jul 2022 16:01:57 -0000

--00000000000011d51305e3c605c3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

it's in line with the values of

 - immutable supply
 - enforced by the game theory of hard money

and no, it's not only "rich holders"... i mine, and lots of people i know d=
o

it's certainly more decentralized than the alternatives




On Thu, Jul 14, 2022 at 7:43 AM Gino Pinuto <gino.pinuto@gmail.com> wrote:

> This is not an argument in line with bitcoin values, on that scenario onl=
y
> rich people will be able to mine and participate to the consensus process=
.
> Like George Soros today, he use its financial reserves to monopolize ONG
> in order to manipulate nation states. I would not define this a "tax",
> moreover a cost to maintain control over the network.
>
> Those rich holders could crate a cartel and without market dynamics all
> game theory stop to work and the bitcoin network value drop.
>
> We should think about how to maximise the network value instead of trying
> to preserve it with corruptible practices outside of market dynamics
> principles.
>
> On Thu, 14 Jul 2022, 12:53 Erik Aronesty via bitcoin-dev, <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Fees and miner rewards are not needed at all for security at all since
>> long term holders can simply invest in mining to secure the value of the=
ir
>> stake.
>>
>> Isn't it enough that the protocol has a mechanism to secure value?
>>
>> Sure fees *might* be enough.
>>
>> But in the event that they are not, large holders can burn a bit to make
>> sure the hashrate stays high.
>>
>> I know, I know it's a tax on the rich and it's not fair because smaller
>> holders are less likely to do it, but it's a miniscule tax even in the
>> worst case
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Jul 14, 2022, 5:35 AM vjudeu via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> > This specific approach would obviously not work as most of those
>>> outputs would be dust and the miner would need to waste an absurd amoun=
t of
>>> block space just to grab them, but maybe there's a smarter way to do it=
.
>>>
>>> There is a smarter way. Just send 0.01 BTC per block to the timelocked
>>> outputs. Now, we have 6.25 BTC, so it means less than 0.2%. But that
>>> percentage will grow over time, as basic block reward will shrink, and =
we
>>> will have mandatory 0.01 BTC endlessly moved, until it will wrap. And g=
uess
>>> what: if it will be 0.01 BTC per block, wrapped every 210,000 blocks, i=
t
>>> simply means you can lock 2,100 BTC in an endless circulation loop, and
>>> avoid this "tail supply attack".
>>>
>>> So, fortunately, even if "tail supply attackers" will win, we will stil=
l
>>> have a chance to counter-attack by burning those coins, or (even better=
) by
>>> locking them in an endless circulation loop, just to satisfy their
>>> malicious soft-fork, whatever amount it will require. Because even if i=
t
>>> will be mandatory to timelock 0.01 BTC to the current block number plus
>>> 210,000, then it is still perfectly valid to move that amount endlessly=
,
>>> without taking it, just to resist this "tail supply attack".
>>>
>>>
>>> On 2022-07-13 20:01:39 user Manuel Costa via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> > What about burning all fees and keep a block reward that will smooth
>>> out while keeping the ~21M coins limit ?
>>>
>>> This would be a hard fork afaict as it would go against the rules of th=
e
>>> coinbase transaction following the usual halving schedule.
>>>
>>> However, if instead we added a rule that fees have to be sent to an
>>> anyone can spend output with a timelock we might be able to achieve a
>>> similar thing.
>>>
>>> Highly inefficient example:
>>>
>>> - Split blocks into 144 (about a day)
>>> - A mined block takes all the fees and distributes them equally into 14=
4
>>> new outputs (anyone can spend) time locked to each of the 144 blocks of=
 the
>>> next day.
>>> - Next day, for each block, we'd have available an amount equivalent to
>>> the previous day total fees / 144. So we deliver previous day's fees
>>> smoothed out.
>>>
>>> Notes:
>>> 144 is arbitrary in the example.
>>> This specific approach would obviously not work as most of those output=
s
>>> would be dust and the miner would need to waste an absurd amount of blo=
ck
>>> space just to grab them, but maybe there's a smarter way to do it.
>>>
>>>
>>>
>>>
>>> Gino Pinuto via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
>>> escreveu no dia quarta, 13/07/2022 =C3=A0(s) 13:19:
>>> What about burning all fees and keep a block reward that will smooth ou=
t
>>> while keeping the ~21M coins limit ?
>>>
>>>
>>> Benefits :
>>> - Miners would still be incentivized to collect higher fees transaction
>>> with the indirect perspective to generate more reward in future.
>>> - Revenues are equally distributed over time to all participants and we
>>> solve the overnight discrepancy.
>>> - Increased velocity of money will reduce the immediate supply of
>>> bitcoin cooling down the economy.
>>> - Reduction of velocity will have an impact on miners only if it
>>> persevere in the long term but short term they will still perceive the
>>> buffered reward.
>>>
>>>
>>> I don't have ideas yet on how to elegantly implement this.
>>>
>>>
>>>
>>> On Wed, 13 Jul 2022, 12:08 John Tromp via bitcoin-dev, <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> > The emission curve lasts over 100 years because Bitcoin success state
>>> requires it to be entrenched globally.
>>>
>>> It effectively doesn't. The last 100 years from 2040-2140 only emits a
>>> pittance of about 0.4 of all bitcoin.
>>>
>>> What matters for proper distribution is the shape of the emission
>>> curve. If you emit 99% in the first year and 1% in the next 100 years,
>>> your emission "lasts" over 100 years, and you achieve a super low
>>> supply inflation rate immediately after 1 year, but it's obviously a
>>> terrible form of distribution.
>>>
>>> This is easy to quantify as the expected time of emission which would
>>> be 0.99 * 0.5yr + 0.01* 51yr =3D 2 years.
>>> Bitcoin is not much better in that the expected time of emission of an
>>> bitcoin satisfies x =3D 0.5*2yr + 0.5*(4+x) and thus equals 6 years.
>>>
>>> Monero appears much better since its tail emission yields an infinite
>>> expected time of emission, but if we avoid infinities by looking at
>>> just the soft total emission [1], which is all that is emitted before
>>> a 1% yearly inflation, then Monero is seen to actually be a lot worse
>>> than Bitcoin, due to emitting over 40% in its first year and halving
>>> the reward much faster. Ethereum is much worse still with its huge
>>> premine and PoS coins like Algorand are scraping the bottom with their
>>> expected emission time of 0.
>>>
>>> There's only one coin whose expected (soft) emission time is larger
>>> than bitcoin's, and it's about an order of magnitude larger, at 50
>>> years.
>>>
>>> [1]
>>> https://john-tromp.medium.com/a-case-for-using-soft-total-supply-1169a1=
88d153
>>> _______________________________________________
>>> 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
>>>
>>> _______________________________________________
>>> 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
>>
>

--00000000000011d51305e3c605c3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">it&#39;s in line with the values of<div><br></div><div>=C2=
=A0- immutable=C2=A0supply</div><div>=C2=A0- enforced by the game theory of=
 hard money</div><div><br></div><div>and no, it&#39;s not only &quot;rich h=
olders&quot;... i mine, and lots of people i know do</div><div><br></div><d=
iv>it&#39;s certainly more decentralized than the alternatives</div><div><b=
r></div><div><br></div><div><br></div></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jul 14, 2022 at 7:43 AM Gino =
Pinuto &lt;<a href=3D"mailto:gino.pinuto@gmail.com">gino.pinuto@gmail.com</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv dir=3D"auto">This is not an argument in line with bitcoin values, on tha=
t scenario only rich people will be able to mine and participate to the con=
sensus process.<div dir=3D"auto">Like George Soros today, he use its financ=
ial reserves to monopolize ONG in order to manipulate nation states. I woul=
d not define this a &quot;tax&quot;, moreover a cost to maintain control ov=
er the network.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Those ri=
ch holders could crate a cartel and without market dynamics all game theory=
 stop to work and the bitcoin network value drop.</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">We should think about how to maximise the network=
 value instead of trying to preserve it with corruptible practices outside =
of market dynamics principles.</div></div><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr" class=3D"gmail_attr">On Thu, 14 Jul 2022, 12:53 Erik Aronest=
y via bitcoin-dev, &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.=
org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"aut=
o">Fees and miner rewards are not needed at all for security at all since l=
ong term holders can simply invest in mining to secure the value of their s=
take.<div dir=3D"auto"><br></div><div dir=3D"auto">Isn&#39;t it enough that=
 the protocol has a mechanism to secure value?</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">Sure fees *might* be enough.=C2=A0=C2=A0</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">But in the event that they are not,=
 large holders can burn a bit to make sure the hashrate stays high.</div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">I know, I know it&#39;s a tax o=
n the rich and it&#39;s not fair because smaller holders are less likely to=
 do it, but it&#39;s a miniscule tax even in the worst case</div><div dir=
=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div=
><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">=
<br></div><div dir=3D"auto"><br><div dir=3D"auto"><br></div></div></div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, J=
ul 14, 2022, 5:35 AM vjudeu via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-d=
ev@lists.linuxfoundation.org" rel=3D"noreferrer" target=3D"_blank">bitcoin-=
dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">&gt; This specific approach would obviously no=
t work as most of those outputs would be dust and the miner would need to w=
aste an absurd amount of block space just to grab them, but maybe there&#39=
;s a smarter way to do it.<br>
<br>
There is a smarter way. Just send 0.01 BTC per block to the timelocked outp=
uts. Now, we have 6.25 BTC, so it means less than 0.2%. But that percentage=
 will grow over time, as basic block reward will shrink, and we will have m=
andatory 0.01 BTC endlessly moved, until it will wrap. And guess what: if i=
t will be 0.01 BTC per block, wrapped every 210,000 blocks, it simply means=
 you can lock 2,100 BTC in an endless circulation loop, and avoid this &quo=
t;tail supply attack&quot;.<br>
<br>
So, fortunately, even if &quot;tail supply attackers&quot; will win, we wil=
l still have a chance to counter-attack by burning those coins, or (even be=
tter) by locking them in an endless circulation loop, just to satisfy their=
 malicious soft-fork, whatever amount it will require. Because even if it w=
ill be mandatory to timelock 0.01 BTC to the current block number plus 210,=
000, then it is still perfectly valid to move that amount endlessly, withou=
t taking it, just to resist this &quot;tail supply attack&quot;.<br>
<br>
<br>
On 2022-07-13 20:01:39 user Manuel Costa via bitcoin-dev &lt;<a href=3D"mai=
lto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer noreferrer" ta=
rget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; What about burning all fees and keep a block reward that will smooth o=
ut while keeping the ~21M coins limit ?<br>
<br>
This would be a hard fork afaict as it would go against the rules of the co=
inbase transaction following the usual halving schedule.<br>
<br>
However, if instead we added a rule that fees have to be sent to an anyone =
can spend output with a timelock we might be able to achieve a similar thin=
g.<br>
<br>
Highly inefficient example:<br>
<br>
- Split blocks into 144 (about a day)<br>
- A mined block takes all the fees and distributes them equally into 144 ne=
w outputs (anyone can spend) time locked=C2=A0to each of the 144 blocks of =
the next day.<br>
- Next day, for each block, we&#39;d have available an amount equivalent to=
 the previous day total fees / 144. So we deliver previous day&#39;s fees s=
moothed out.<br>
<br>
Notes:<br>
144 is arbitrary in the example.<br>
This specific approach would obviously not work as=C2=A0most of those outpu=
ts would be dust and the miner would need to waste an absurd=C2=A0amount of=
 block space just to grab them, but maybe there&#39;s a smarter way to do i=
t.<br>
<br>
<br>
<br>
<br>
Gino Pinuto via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org" rel=3D"noreferrer noreferrer" target=3D"_blank">bitcoin-dev@l=
ists.linuxfoundation.org</a>&gt; escreveu no dia quarta, 13/07/2022 =C3=A0(=
s) 13:19:<br>
What about burning all fees and keep a block reward that will smooth out wh=
ile keeping the ~21M coins limit ?<br>
<br>
<br>
Benefits :<br>
- Miners would still be incentivized to collect higher fees transaction wit=
h the indirect perspective to generate more reward in future.<br>
- Revenues are equally distributed over time to all participants and we sol=
ve the overnight discrepancy.<br>
- Increased velocity of money will reduce the immediate supply of bitcoin c=
ooling down the economy.<br>
- Reduction of velocity will have an impact on miners only if it persevere =
in the long term but short term they will still perceive the buffered rewar=
d.<br>
<br>
<br>
I don&#39;t have ideas yet on how to elegantly implement this.<br>
<br>
<br>
<br>
On Wed, 13 Jul 2022, 12:08 John Tromp via bitcoin-dev, &lt;<a href=3D"mailt=
o:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer noreferrer" targ=
et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; The emission curve lasts over 100 years because Bitcoin success state =
requires it to be entrenched globally.<br>
<br>
It effectively doesn&#39;t. The last 100 years from 2040-2140 only emits a<=
br>
pittance of about 0.4 of all bitcoin.<br>
<br>
What matters for proper distribution is the shape of the emission<br>
curve. If you emit 99% in the first year and 1% in the next 100 years,<br>
your emission &quot;lasts&quot; over 100 years, and you achieve a super low=
<br>
supply inflation rate immediately after 1 year, but it&#39;s obviously a<br=
>
terrible form of distribution.<br>
<br>
This is easy to quantify as the expected time of emission which would<br>
be 0.99 * 0.5yr + 0.01* 51yr =3D 2 years.<br>
Bitcoin is not much better in that the expected time of emission of an<br>
bitcoin satisfies x =3D 0.5*2yr + 0.5*(4+x) and thus equals 6 years.<br>
<br>
Monero appears much better since its tail emission yields an infinite<br>
expected time of emission, but if we avoid infinities by looking at<br>
just the soft total emission [1], which is all that is emitted before<br>
a 1% yearly inflation, then Monero is seen to actually be a lot worse<br>
than Bitcoin, due to emitting over 40% in its first year and halving<br>
the reward much faster. Ethereum is much worse still with its huge<br>
premine and PoS coins like Algorand are scraping the bottom with their<br>
expected emission time of 0.<br>
<br>
There&#39;s only one coin whose expected (soft) emission time is larger<br>
than bitcoin&#39;s, and it&#39;s about an order of magnitude larger, at 50<=
br>
years.<br>
<br>
[1] <a href=3D"https://john-tromp.medium.com/a-case-for-using-soft-total-su=
pply-1169a188d153" rel=3D"noreferrer noreferrer noreferrer" target=3D"_blan=
k">https://john-tromp.medium.com/a-case-for-using-soft-total-supply-1169a18=
8d153</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer"=
 target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>

--00000000000011d51305e3c605c3--