From: jk_14@op.pl
To: Billy Tetrud <billy.tetrud@gmail.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary
Date: Thu, 18 Aug 2022 22:22:30 +0200 [thread overview]
Message-ID: <73900259-c5361e151c592be1534bf37720d1ebcf@pmq6v.m5r2.onet> (raw)
Fortunately halving in 2020 will be non destructive because it looks like we will have higher difficulty in 2024 than in 2020.
Let's assume the worst case scenario: after halving in 2024, we have regression 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 ecosystem to show us what is the equilibrium/saturation level at globe scale - I hope it will be several years later and "the annual inflation to keep" - will 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 reward (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. Empirically reached security level is - the most accurate one. In military terminology: 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 pathological Friedman's "free lunches" for stakeholders, due to this overtaxing (punish) people which are simply want to use Bitcoin, additionally with pure 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 proportionally to holdings - and instead of it we rather prefer to take the high risk of 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żytkownik Billy Tetrud <billy.tetrud@gmail.com> napisał:
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* solve the potential problem of mining rewards, it only delays it. A tail emission of 200,000 btc/year (~1% of the current supply) would be equivalent to halvings every ~50 years rather than every 4 years. Were we to implement 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 stable 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 rate per year is an absurdly high estimate these days, and the loss rate is likely 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 imagining people losing $10 billion of bitcoin every year. Highly unlikely IMO. 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 difference even over 100s of years.
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 example, 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 example, every block could emit new bitcoin amounting to 10% of the fees collected in that block. This would tie coinbase rewards to the real world (since the fee market is tied to the real economy) and ensure higher block revenue indefinitely - ie not just for another 50 years.
But its also worth saying that blockchain security (which mining revenue correlates with) does *not* need to increase indefinitely. There is some amount of security (and therefore some amount of mining revenue) that is sufficient, beyond which additional security is simply unnecessary, unwarranted, and wasteful (you wouldn't buy a $1000 safe to store $1000 of valuables). Do we, as the bitcoin community, have some good idea how much security we need? Do we have some idea how costly a 51% attack must be where we can be comfortable it will never happen? I'm curious to hear what people think about that. Because without having some kind of estimates of what "enough security" is, there's absolutely no way of evaluating whether or not its likely that bitcoin fees alone will be able to sustain enough security.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
next reply other threads:[~2022-08-18 20:22 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-18 20:22 jk_14 [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-08-19 5:34 [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary vjudeu
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-08-15 21:46 jk_14
2022-08-17 11:10 ` Erik Aronesty
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=73900259-c5361e151c592be1534bf37720d1ebcf@pmq6v.m5r2.onet \
--to=jk_14@op.pl \
--cc=billy.tetrud@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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