From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5837FC002D for ; 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 ; 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 ; 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 ; 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 , Bitcoin Protocol Discussion Date: Thu, 18 Aug 2022 22:22:30 +0200 Message-Id: <73900259-c5361e151c592be1534bf37720d1ebcf@pmq6v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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