path: root/c4/69a53b0b0e88aeb765bd307c8f7d638a1e7874

Return-Path: <jk_14@op.pl>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 5837FC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Aug 2022 20:22:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 3008A418F6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Aug 2022 20:22:42 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 3008A418F6
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (1024-bit key) header.d=op.pl header.i=@op.pl header.a=rsa-sha256
 header.s=2011 header.b=KWHwwFur
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham 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 xMDn70F0G4Kh
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Aug 2022 20:22:40 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org D005841862
Received: from smtpo115.poczta.onet.pl (smtpo115.poczta.onet.pl
 [213.180.149.168])
 by smtp4.osuosl.org (Postfix) with ESMTPS id D005841862
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 18 Aug 2022 20:22:39 +0000 (UTC)
Received: from pmq6v.m5r2.onet (pmq6v.m5r2.onet [10.174.33.77])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4M7xBv0DRCzlhyb7;
 Thu, 18 Aug 2022 22:22:30 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=op.pl; s=2011;
 t=1660854151; bh=xrKs1o+0u62gPOMcrrhaHS5++XR1SIBNrUY2XOwI8iw=;
 h=From:Cc:To:Date:Subject:From;
 b=KWHwwFurEtQTgVht9zY8mw/NuPV1Wg87UsEsYAndHJyRe7luoXHe81qvr1w1cph7x
 PPWNqvKWo0JU1ueb2RyEJHzYJIpOI/ykV8cnzwCnyeG5UkqjNiuRTuVVnAw9Q19DRH
 829gzAem7JhC224H+XS30Bn2RQIVSjFSJn1vNXLU=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [89.64.64.124] by pmq6v.m5r2.onet via HTTP id ;
 Thu, 18 Aug 2022 22:22:30 +0200
From: jk_14@op.pl
X-Priority: 3
To: Billy Tetrud <billy.tetrud@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Date: Thu, 18 Aug 2022 22:22:30 +0200
Message-Id: <73900259-c5361e151c592be1534bf37720d1ebcf@pmq6v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <jk_144@onet.pl>;89.64.64.124;PL;4
X-ONET_PL-MDA-SEGREGATION: 0
X-Mailman-Approved-At: Thu, 18 Aug 2022 21:38:44 +0000
Subject: Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary
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, 18 Aug 2022 20:22:42 -0000


Fortunately halving in 2020 will be non destructive because it looks like w=
e will have higher difficulty in 2024 than in 2020.

Let's assume the worst case scenario: after halving in 2024, we have regres=
sion of difficulty in 2028. Annual inflation rate in 2028 is 0.81%. Removal=
 of halvings in this year means that in year 2100 (72 years later) we will =
have 0.51% annual inflation rate, still. And that is Monero concept in fact=
: constant annual supply, thus very slowly decreasing of inflation.

Yes, you are right. Better that that - would be to wait for bitcoin ecosyst=
em to show us what is the equilibrium/saturation level at globe scale - I h=
ope it will be several years later and "the annual inflation to keep" - wil=
l be 0.40% in 2032 or even 0.20% only in 2036.

And then instead of halving every 210k blocks - just to adjust the block re=
ward (i.e. slightly increase). To keep the annual inflation rate constant. =
Constant forever. On most proper level - because determined empirically. I =
didn't propose it, because of certain, immediate backlash :)

And for the same reason, as an answer how much security we need. Empiricall=
y reached security level is - the most accurate one. In military terminolog=
y: the protection of already conquered land. Regression is sign of weakness=
 and we probably don't want to see it in Bitcoin.

Anyway, keeping Bitcoin in the middle of ultra-obvious Edge Case, with path=
ological Friedman's "free lunches" for stakeholders, due to this overtaxing=
 (punish) people which are simply want to use Bitcoin, additionally with pu=
re form of Prisoner's Dilemma here, and with Trust to "large" stakeholders,=
 while almost every of them will convince himself he is not really a large =
one and "let Microstrategy run Antminers" (and burn money)

- and all above only because we are too greed to pay miners as low as only =
few tenths of a percent per year for their real service as keeping network =
secure, pay in most honest way, because with no exceptions and proportional=
ly to holdings - and instead of it we rather prefer to take the high risk o=
f spiral of death - is madness.


Pure madness. This is what almost 50y old cynic may assure you.

Regards
Jaroslaw




W dniu 2022-08-18 17:44:29 u=C5=BCytkownik Billy Tetrud <billy.tetrud@gmail=
.com> napisa=C5=82:
While constant tail emission does in fact converge to 0 inflation over time=
 (which bitcoin's halvings do as well mind you), tail emission does *not* s=
olve the potential problem of mining rewards, it only delays it. A tail emi=
ssion of 200,000 btc/year (~1% of the=C2=A0current supply) would be equival=
ent to halvings every ~50 years rather than every 4 years. Were we to imple=
ment this kind of thing right after the last non-" destructive" halving, it=
 would buy us 46 years of extra time. Nothing more, nothing less.

While its mildly interesting to know that tail emission converges to a stab=
le point, while no inflation implies monetary deflation at the rate of loss=
, this feels very likely to be an insignificant problem. I think 1% loss ra=
te per year is an absurdly high estimate these days, and the loss rate is l=
ikely to decrease as methods of storing bitcoin mature. Imagine bitcoin was=
 worth $1 trillion (not so hard, since it was not too long ago), then try i=
magining people losing $10 billion of bitcoin every year. Highly unlikely I=
MO. A rate of loss of 0.01%/year might be more realistic for a near-future =
mature bitcoin. That's not going to be enough to make a significant differe=
nce=C2=A0even over 100s of years.=C2=A0

If we actually wanted to solve the potential problem of not-enough-fees to =
upkeep mining security, there are less temporary ways to solve that. For ex=
ample, if fees end up not being able to support sufficient mining, we could=
 add emission based on a constant fraction of fees in the block. For exampl=
e, every block could emit new bitcoin amounting to 10% of the fees collecte=
d in that block. This would tie coinbase rewards to the real world (since t=
he fee market is tied to the real economy) and ensure higher block revenue =
indefinitely - ie not just for another=C2=A050 years.=C2=A0

But its also worth saying that blockchain security (which mining revenue co=
rrelates with) does *not* need to increase indefinitely. There is some amou=
nt of security (and therefore some amount of mining revenue) that is suffic=
ient, beyond which additional security is simply unnecessary, unwarranted, =
and wasteful (you wouldn't buy a $1000 safe to store $1000 of valuables). D=
o we, as the bitcoin community, have some good idea how much security we ne=
ed? Do we have some idea how costly a 51% attack must be where we can be co=
mfortable it will never happen? I'm curious to hear what people think about=
 that. Because without having some kind of estimates of what "enough securi=
ty" is, there's absolutely no way of evaluating whether or not its likely t=
hat bitcoin fees alone will be able to sustain enough security.=C2=A0


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev