path: root/4d/62874ded9ae65f23dcb3df63c90e3275b1b8c0

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