path: root/64/97295ab60aef9af081e7da7a774c3e8d32a134

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--