From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <jk_14@op.pl> Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 35E71C002D for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 15 Aug 2022 21:47:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 0852B403F8 for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 15 Aug 2022 21:47:06 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 0852B403F8 Authentication-Results: smtp2.osuosl.org; dkim=pass (1024-bit key) header.d=op.pl header.i=@op.pl header.a=rsa-sha256 header.s=2011 header.b=qEixNcC2 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnEc1yPFyVri for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 15 Aug 2022 21:47:04 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 630304032B Received: from smtpo97.poczta.onet.pl (smtpo97.poczta.onet.pl [213.180.149.150]) by smtp2.osuosl.org (Postfix) with ESMTPS id 630304032B for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 15 Aug 2022 21:47:04 +0000 (UTC) Received: from pmq1v.m5r2.onet (pmq1v.m5r2.onet [10.174.32.67]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4M67Cg2XVFzlgF6g; Mon, 15 Aug 2022 23:46:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=op.pl; s=2011; t=1660600015; bh=MTfdN+2aYYW4jM9HvwovZLVYhmJYAPyUcWr4gYfM7Jo=; h=From:To:Date:Subject:From; b=qEixNcC2bME2h4vD+8zKc870DCgCBFs58vH2DQ+yuypxISLFc49ToGrhB4Tj9SUMB kUVP+VYTBADZzCEzHHvBQ2SSmG36gPl7Xb1ORbnphCEOoz4a3vObRMIfSCTiU1Gcg8 VuRQqqC+L6AhD0wdf7o4KZgOlbFLPTQT3HmCLfaM= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [89.64.65.189] by pmq1v.m5r2.onet via HTTP id ; Mon, 15 Aug 2022 23:46:55 +0200 From: jk_14@op.pl X-Priority: 3 To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, "pete@petertodd.org" <pete@petertodd.org> Date: Mon, 15 Aug 2022 23:46:52 +0200 Message-Id: <166771656-fdf60b77a66e05a55a2e75479a31e5f7@pmq1v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: <jk_144@onet.pl>;89.64.65.189;PL;2 X-ONET_PL-MDA-SEGREGATION: 0 X-Mailman-Approved-At: Tue, 16 Aug 2022 01:59:02 +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: Mon, 15 Aug 2022 21:47:06 -0000 > New blog post: > https://petertodd.org/2022/surprisingly-tail-emission-is-not-inflationary Tail emission is inevitable, Milton Friedman says... The key thing here in my opinion is to properly understand the seriousness = of the situation. "There is no such thing as a free lunch" - is definitely helpful quote here. There are two edge cases. 1. while starting given cryptocurrency - the annual inflation is huge, nobody (in developed/mature monetary system= ) would like to keep such kind of money with e.g. 100% annual inflation rat= e, but from the other side there is no problem for transaction fee to be fr= ee of charge here 2. while given cryptocurrency is switching off the block reward, in suppose= d "mature phase": - the annual inflation is zero, everyone want to hoard such money, transact= ion fees must carry the whole security of the system In the first edge case: active users have got "free lunches" and passive us= ers (i.e. holders) are paying for it (by "inflation tax") In the second edge case: passive users have got "free lunches" and active u= sers should pay for it (by "transactional tax") So far I only highlighted some maybe not very well recognized, but pure fac= ts (it's not comfortable to contradict the facts...) The reason people do pay in the first phase - is a hope/promise of system g= rowth (future coin price appreciation =3D profit) The problem in the second phase is that there is no real incentive for peop= le to pay for other's free lunches. Any wishful thinking that most (or even: any significant part) of holders w= ill resign from a free lunch and will buy and run ASIC mining equipment at = loss - is just a delusional perspective. It's well proven by game theory an= d what says us the Prisoner's Dilemma about it. For better understanding - = here is my modified version of Prisoner's Dilemma short description: "The Prisoner's Dilemma is a standard example of a game analyzed in game th= eory that shows why completely rational large holders might not cooperate, = even if it appears that it is in their best interests to do so." I'm pretty sure we will have a textbook case of Prisoner's Dilemma here. As a useful example - let's assume that fees don't compensate low block rew= ard. Btw, right now a single transaction fee need to be $60 to compensate t= hat (and it will only get worse in time). System is not inclusive with $60 = per transaction fee. Only rich people will use it. Another possible scenari= o is a x100 drop of network hashrate to catch a previous fee levels. The ne= twork is x100 less secure, then. It really doesn't matter if this process i= s spread over the long run... So, for example - let every 10 BTC holding needs to be secured by one Antmi= ner S19 running. In an ideal world every large bitcoin holder will run proper amount of ASIC= s and run it at loss. The holders of less than 10 BTC - will organize "group pays", this time for= sharing loss (electricity costs) Exactly the same way like people made "group buys" of ASIC hardware in 2013. I hope it's clear that in the real world it WILL NOT work. People will simp= ly think, that there is only a tiny punishment for betrayal. Noone will waste his renewable energy on unprofitable Antminer while he/she= can sell this energy for the market price. Even Bitcoin can't beat the hum= an nature. Thanks to Milton Friedman - we can easily say that situation with "free lun= ches" (at least for some part of users) - is an unhealthy state of financia= l system. And may last only exceptionally for short period of time, and definitely no= t as a default state. System must be sustainable and time to accept that th= ere is a real problem here (or: an elephant in the room - but maybe not suc= h invisible like was before). The good news is a natural solution exists. Bitcoin can solve this issue na= tural way. While decreasing block reward and moving from the first edge case to the se= cond one - the system naturally cross the Area of Balance. And healthy system should stay somewhere in such area. And that's exactly w= hat Monero did. But they did it arbitrally, at 0.9% level. Bitcoin is able to do it much better - because empirically. There is a simple trigger if the system is leaving an Area of Balance and c= ross the line of Phase 2 with "free lunches". The network difficulty / glob= al network hashrate chart. Four years after some particular halving (in 2028, 2032 or later - no matte= r when in fact) - we will (definitely) see difficulty is not recovered duri= ng four long years. This is a big red light. It means that halvings starts to be destructive to= the network security. = Something what became destructive to the network - must be removed. Halving= must be removed in such moment. Moment determined empirically - what is go= od thing. Satoshi Nakamoto wasn't able to properly predict when this moment= may appear, but we are in better situation. "Bitcoin to the moon" (and any other pro-21M hardcap shortsighted slogans) = - must have a lower priority than network security/health. I'm sure Satoshi would agree with it. Of course, someone may set up such en= vironment, where holders (i.e. passive users) have got a free lunches and security of network is based on active users' shoulders only. Someone c= ould even insist that it is quite fair... But please don't expect a lack of impact for the network security where not= all, but only a part of users - participate in supporting network health. Many people don't realise a simple fact: keeping destructive halvings in su= ch situation above, just for maximising appreciation of already hoarded coi= ns - is counterproductive. Because the network security is decreasing. We have a lot of time yet to educate people about it - for reaching common = consensus for halvings removal with "ease". We should probably use Milton Friedman's quote and highlight that balanced = system with 0.45% / 0.225% / 0.1125% (?) annual inflation rate (and slowly = decreasing) - is still enormously better than any surrounding fiat system. But system s= till balanced and stable - and not in spiral of death... =E2=80=9CBitcoin should have had a 0.1% or 1% monetary inflation tax to pay= for security,=E2=80=9D Peter said long time ago, further arguing bitcoin w= ill die if it doesn=E2=80=99t change the limit. I fully agree with Peter. The halvings should be removed in case it starts = to be destructive to the network security (lack of hashrate recovery during= long 4 years after given halving). Because that means bitcoin system has r= eached equilibrium / saturation on a globe scale level. The evolutionary pa= th is the best path. The worst path is: overcomplicated constructs, completely unclear for Avera= ge Joe. Additional merge-mining coins, whatever etc. - just to achieve the = same final goal. KISS =3D Keep It Simple. Halving removal is the most honest, simplest and m= ost understandable way to make every bitcoin pasive user to participate in = keeping Bitcoin network secure. It just force the rule, that someone pay pr= oportionally to amount of bitcoins he/she hold, and all participants are su= re that everybody participate (no Prisoner's Dilemma, what is crucial matte= r) Yes, that means: hard fork. But as written above - Bitcoin will die without= the solution. Bitcoin may be also out of sudden in a deadly risk from quantum computers. = In such circumstances everyone (or: almost, i.e. everyone who cares) - woul= d immediately download a quantum resistant, freshly released bitcoin wallet= , no doubt. And these two dangers are similar at least in one aspect: both = will cause the spiral of death. Widespread consensus would be the best scenario, but from the other side: a= fork always shows retrospectively, who was right (BCH turmoil in 2017) Regards Jaroslaw P.S some other resources yet: "Friedman originally proposed a fixed monetary rule, called Friedman's k-pe= rcent rule, where the money supply would be automatically increased by a fi= xed percentage per year. Under this rule, there would be no leeway for the = central reserve bank, as money supply increases could be determined "by a c= omputer", and business could anticipate all money supply changes. With othe= r monetarists he believed that the active manipulation of the money supply = or its growth rate is more likely to destabilise than stabilise the economy. Most monetarists oppose the gold standard. Friedman, for example, viewed a = pure gold standard as impractical.[9] For example, whereas one of the benef= its of the gold standard is that the intrinsic limitations to the growth of= the money supply by the use of gold would prevent inflation, if the growth= of population or increase in trade outpaces the money supply, there would = be no way to counteract deflation and reduced liquidity (and any attendant = recession) except for the mining of more gold" no block reward =3D> reduced liquidity (reduced number of transactions) = =3D> network security in spiral of death https://en.wikipedia.org/wiki/Monetarism https://en.wikipedia.org/wiki/Friedman%27s_k-percent_rule https://twitter.com/hasufl/status/1511470668457652224 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev