public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: jk_14@op•pl
To: Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>,
	"pete@petertodd•org" <pete@petertodd•org>
Subject: Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary
Date: Mon, 15 Aug 2022 23:46:52 +0200	[thread overview]
Message-ID: <166771656-fdf60b77a66e05a55a2e75479a31e5f7@pmq1v.m5r2.onet> (raw)


> 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 rate, but from the other side there is no problem for transaction fee to be free of charge here

2. while given cryptocurrency is switching off the block reward, in supposed "mature phase":
- the annual inflation is zero, everyone want to hoard such money, transaction fees must carry the whole security of the system


In the first edge case: active users have got "free lunches" and passive users (i.e. holders) are paying for it (by "inflation tax")
In the second edge case: passive users have got "free lunches" and active users should pay for it (by "transactional tax")

So far I only highlighted some maybe not very well recognized, but pure facts (it's not comfortable to contradict the facts...)


The reason people do pay in the first phase - is a hope/promise of system growth (future coin price appreciation = profit)
The problem in the second phase is that there is no real incentive for people to pay for other's free lunches.


Any wishful thinking that most (or even: any significant part) of holders will 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 and 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 theory 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 reward. Btw, right now a single transaction fee need to be $60 to compensate that (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 scenario is a x100 drop of network hashrate to catch a previous fee levels. The network is x100 less secure, then. It really doesn't matter if this process is spread over the long run...

So, for example - let every 10 BTC holding needs to be secured by one Antminer S19 running.

In an ideal world every large bitcoin holder will run proper amount of ASICs 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 simply 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 human nature.


Thanks to Milton Friedman - we can easily say that situation with "free lunches" (at least for some part of users) - is an unhealthy state of financial system.
And may last only exceptionally for short period of time, and definitely not as a default state. System must be sustainable and time to accept that there is a real problem here (or: an elephant in the room - but maybe not such invisible like was before).

The good news is a natural solution exists. Bitcoin can solve this issue natural way.

While decreasing block reward and moving from the first edge case to the second one - the system naturally cross the Area of Balance.
And healthy system should stay somewhere in such area. And that's exactly what 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 cross the line of Phase 2 with "free lunches". The network difficulty / global network hashrate chart.
Four years after some particular halving (in 2028, 2032 or later - no matter when in fact) - we will (definitely) see difficulty is not recovered during 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 good 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 environment, where holders (i.e. passive users) have got a free lunches
and security of network is based on active users' shoulders only. Someone could 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 such situation above, just for maximising appreciation of already hoarded coins
- 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 still balanced and stable - and not in spiral of death...


“Bitcoin should have had a 0.1% or 1% monetary inflation tax to pay for security,” Peter said long time ago, further arguing bitcoin will die if it doesn’t 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 reached equilibrium / saturation on a globe scale level. The evolutionary path is the best path.
The worst path is: overcomplicated constructs, completely unclear for Average Joe. Additional merge-mining coins, whatever etc. - just to achieve the same final goal.
KISS = Keep It Simple. Halving removal is the most honest, simplest and most understandable way to make every bitcoin pasive user to participate in keeping Bitcoin network secure. It just force the rule, that someone pay proportionally to amount of bitcoins he/she hold, and all participants are sure that everybody participate (no Prisoner's Dilemma, what is crucial matter)


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) - would 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-percent rule, where the money supply would be automatically increased by a fixed 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 computer", and business could anticipate all money supply changes. With other 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 benefits 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  => reduced liquidity (reduced number of transactions) => 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




             reply	other threads:[~2022-08-15 21:47 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-15 21:46 jk_14 [this message]
2022-08-17 11:10 ` Erik Aronesty
  -- strict thread matches above, loose matches on Subject: below --
2022-08-19  5:34 vjudeu
2022-08-18 20:22 jk_14
2022-08-17 13:43 jk_14
2022-08-18 15:29 ` Breno Brito
2022-08-18 15:44 ` Billy Tetrud
2022-08-18 20:49 ` Erik Aronesty
2022-08-17  8:54 jk_14
2022-08-16 16:05 Peter
2022-08-19 17:21 ` aliashraf.btc At protonmail
2022-08-20 15:30   ` Billy Tetrud
2022-07-26 20:01 jk_14
2022-07-19 18:36 Peter
2022-07-20 14:35 ` Eric Voskuil
2022-07-10 17:42 Eric Voskuil
     [not found] <mailman.80287.1657405305.8511.bitcoin-dev@lists.linuxfoundation.org>
2022-07-10  7:44 ` John Tromp
2022-07-09 22:21 Peter
2022-07-09 20:54 Eric Voskuil
2022-07-09 21:59 ` ZmnSCPxj
2022-07-10 14:17   ` alicexbt
2022-07-10 16:38     ` alicexbt
2022-07-10 17:29     ` Peter Todd
2022-07-10 17:27   ` Peter Todd
2022-07-10 18:12     ` vjudeu
2022-07-18 11:34     ` David A. Harding
2022-07-18 19:14       ` Erik Aronesty
2022-07-18 21:48         ` Eric Voskuil
2022-07-25 15:04         ` Erik Aronesty
2022-07-26 15:44           ` jk_14
2022-07-26 17:05             ` Erik Aronesty
2022-07-09 20:53 Eric Voskuil
2022-07-09 14:57 John Tromp
2022-07-09 15:13 ` Peter Todd
2022-07-11 18:44   ` Dave Scotese
2022-07-09 12:46 Peter Todd
2022-07-09 14:26 ` Eric Voskuil
2022-07-09 15:15   ` Peter Todd
2022-07-09 15:24     ` Eric Voskuil
2022-07-09 15:31       ` Peter Todd
2022-07-09 17:43         ` naman naman
2022-07-09 17:48           ` Peter Todd
2022-07-10  6:54             ` naman naman
2022-07-10  2:10         ` Tobin Harding
2022-07-10  7:08 ` vjudeu
2022-07-11 18:25   ` Larry Ruane
2022-07-10 10:18 ` Jacob Eliosoff
2022-07-11  2:32 ` Anthony Towns
2022-07-11  6:15   ` Stefan Richter
2022-07-11 10:42     ` Giuseppe B
2022-07-11 12:56   ` Erik Aronesty
2022-07-11 23:57     ` Anthony Towns
2022-07-13 18:29       ` Zac Greenwood
2022-07-11 16:59   ` Peter Todd
2022-07-11 17:44     ` Bram Cohen
2022-07-13 14:06 ` Alfred Hodler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=166771656-fdf60b77a66e05a55a2e75479a31e5f7@pmq1v.m5r2.onet \
    --to=jk_14@op$(echo .)pl \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=pete@petertodd$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox