path: root/86/15c469f5b47c413f462c728c9d8e3994892836

Return-Path: <manecosta@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 5843AC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 14 Jul 2022 16:28:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 2289340477
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 14 Jul 2022 16:28:12 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 2289340477
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=FriTUHVB
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Xh5LUPix9aLV
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 14 Jul 2022 16:28:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 21E7D40114
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com
 [IPv6:2a00:1450:4864:20::334])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 21E7D40114
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 14 Jul 2022 16:28:10 +0000 (UTC)
Received: by mail-wm1-x334.google.com with SMTP id
 az2-20020a05600c600200b003a301c985fcso1284149wmb.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 14 Jul 2022 09:28:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=3Td3G9ZD7C4hMvikZHR1pB1onkOVc6Z68DAWYPdHdhw=;
 b=FriTUHVBm5F8rjE3wL9R4b5btYK2P8wNxxtZbEpiQJd7fuLqufPFBWY8mrVnjTOoBS
 9keslpFBaSX7OVyZF/r9hCbJ+kt442CjptNUYEjl0V9T9LkMcovfxpfEilcpz2MGz5Rb
 MFJZDxgfkA+NruD0BQ/Qn5M4Llnw5HXgpjPvqAiq9rplKztqd2or7UKzz1wgcCICl7dV
 wHOW+SN7j11w2qhXI5yUtlwmdtYcut9vwLUYcnOA+/9EKW7ASkoP4HmL99Hkh7UitZui
 QbWjG6cm6VmgiG6qC1zBYwauVp/HOpa7+rZukkcAWb7HQFY3wQsv1kZnITG2stxu2KGv
 S1mg==
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=3Td3G9ZD7C4hMvikZHR1pB1onkOVc6Z68DAWYPdHdhw=;
 b=jvrbxh04BjfpqcIsDE383QzgyIY3IPQ3iNNkfQV2l9FeATRs10Gg9u9aKRrWlN1JGU
 JSS6ZrrSPHRbN33CtaO1Z9jJ1fuX/pOQg7kvhv8vq+CmoF/5LVNENC7gv9Cmzc4m4o+B
 cDG01m7tfYOR5p/V8FKI4xMgh2/MY/vAh0SneuQIk2gFxOplhNCeOJs/HTkCrS2WByjb
 NiZw6jAmPDikwzBe+7mVAVfmIvckkowjRD9yi2tKjJxEoZ60+tcpkCwquHT0ZmT1XHx9
 QBnlU3iMpAjQuVzInxB3vR5E+b940sGItfHUJPDd/xWuF/wbpkCSNSyboVF4ENFWmiq+
 yCfg==
X-Gm-Message-State: AJIora87L/TnEWuwRqPyF9wGEHJxPrZrE03Iid2PCPzC8Zf+Ao2uivlw
 k/hPmLyK+bH45QyyxTCn/BKnsRYQG1LmPU/pi48=
X-Google-Smtp-Source: AGRyM1sCZn7TOwwDFiFOkZyWZd/wtx64AMeC5LKMYjkCvkDrZ1o2sRUCUTZRvlxxceVDRYJ8XUx7CJDPA8nVDN38ibI=
X-Received: by 2002:a05:600c:2ccb:b0:3a2:f171:8d74 with SMTP id
 l11-20020a05600c2ccb00b003a2f1718d74mr13936063wmc.47.1657816088043; Thu, 14
 Jul 2022 09:28:08 -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: Manuel Costa <manecosta@gmail.com>
Date: Thu, 14 Jul 2022 17:27:55 +0100
Message-ID: <CAAxiurZ6qEtQv5q7uXJnZQvh1mDF_sfOVVsR-FXEctbmfkV9LQ@mail.gmail.com>
To: Gino Pinuto <gino.pinuto@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000007e5d805e3c6631e"
X-Mailman-Approved-At: Thu, 14 Jul 2022 16:34:03 +0000
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:28:12 -0000

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

> 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 guess
what: if it 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 "tail supply attack".

My understanding of this is that it would basically remove 0.01 BTC rewards
from the next 210k blocks, and then do nothing.
After 210k blocks have passed, you're just rolling it forward, taking from
the anyone can spend output and locking it in a new one for 210k blocks
from now.
You're basically just using the next 210k block's reward to create a stash
of forever locked coins in a loop.
Unsure how this solves or relates to the smoothing of block rewards. Let me
know if I misunderstood.

Gino Pinuto via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
escreveu no dia quinta, 14/07/2022 =C3=A0(s) 13:18:

> 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
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div dir=3D"ltr">&gt; There is a smarter way. Just send 0.=
01 BTC per block to the timelocked outputs. Now, we have 6.25 BTC, so it me=
ans 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, u=
ntil it will wrap. And guess what: if it will be 0.01 BTC per block, wrappe=
d every 210,000 blocks, it simply means you can lock 2,100 BTC in an endles=
s circulation loop, and avoid this &quot;tail supply attack&quot;.<br><br>M=
y understanding of this is that it would basically remove 0.01 BTC rewards =
from the next 210k blocks, and then do nothing.<br>After 210k blocks have p=
assed, you&#39;re just rolling it forward, taking from the anyone can spend=
 output and locking it in a new one for 210k blocks from now.<br>You&#39;re=
 basically just using the next 210k block&#39;s reward to create a stash of=
 forever locked coins in a loop.<br>Unsure how this solves or relates to th=
e smoothing of block rewards. Let me know if I misunderstood.<br></div></di=
v><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Gino=
 Pinuto via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; escreveu no dia qui=
nta, 14/07/2022 =C3=A0(s) 13:18:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"auto">This is not an argument in line with bit=
coin values, on that scenario only rich people will be able to mine and par=
ticipate to the consensus process.<div dir=3D"auto">Like George Soros today=
, he use its financial reserves to monopolize ONG in order to manipulate na=
tion states. I would not define this a &quot;tax&quot;, moreover a cost to =
maintain control over the network.</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">Those rich holders could crate a cartel and without market dynam=
ics all game theory stop to work and the bitcoin network value drop.</div><=
div dir=3D"auto"><br></div><div dir=3D"auto">We should think about how to m=
aximise 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"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, 14 Jul 2022,=
 12:53 Erik Aronesty via bitcoin-dev, &lt;<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation=
.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div dir=3D"auto">Fees and miner rewards are not needed at all for secu=
rity at all since long term holders can simply invest in mining to secure t=
he value of their stake.<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 dir=3D"auto"><br></div><div dir=3D"auto">But in the eve=
nt that they are not, large holders can burn a bit to make sure the hashrat=
e stays high.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I know, I =
know it&#39;s a tax on the rich and it&#39;s not fair because smaller holde=
rs 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"gm=
ail_attr">On Thu, Jul 14, 2022, 5:35 AM vjudeu via bitcoin-dev &lt;<a href=
=3D"mailto:bitcoin-dev@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-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">&gt; This specific approac=
h would obviously not work as most of those outputs would be dust and the m=
iner would need to waste 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>
_______________________________________________<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>
</blockquote></div>

--00000000000007e5d805e3c6631e--