public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Billy Tetrud <billy.tetrud@gmail•com>
To: jk_14@op•pl,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary
Date: Thu, 18 Aug 2022 10:44:11 -0500	[thread overview]
Message-ID: <CAGpPWDbD5WQD2Nr6ngiSYtodTkij2N+1Aft5dn5yYePdQ1NC7w@mail.gmail.com> (raw)
In-Reply-To: <73828407-38b211dc3a9d78d44c9b9fb6c2b60b85@pmq6v.m5r2.onet>

[-- Attachment #1: Type: text/plain, Size: 5245 bytes --]

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.



On Wed, Aug 17, 2022 at 9:31 AM Jaroslaw via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

>
> On one scale you puts the Trust to the large stakeholders (why we avoid
> plenty of small stakeholders, btw),
> and on the other side I put game theory and well defined Prisoner's
> Dilemma.
>
> Again: large stakeholders WILL NOT incentivised to mine, they will have
> the hundreds excuses why not to switch-on Antminers back.
> That's how it simply works.  Bitcoin would fail miserably if Satoshi was
> based his concept mainly on existence of idealists.
>
> If we will observe lack of hashrate recovery four years after some halving
> and still unprepared like today
> - means the trust in large stakeholders was a very costly mistake.
>
>
> Superiority of Proof of Work against Proof of Stake has been discussed
> enough either
> The overall conclusion with what I fully agree  is: swapping PoW to PoS -
> would be a degradation.
> You can stop talking about degradation to proof of stake, but just:
> degradation.
>
> Degradation of Bitcoin, due to human greed.
>
> Now you mine and you have an INSTANT gratification.
> Then you will mine and it will cost you real money, but simple switch -
> and you have a DELAYED, maybe some day in the future, maybe only a tiny -
> punishment.
> And The Punishment Won't Be Tiny.
>
>
> "If the pain after hitting the hand with a hammer would appear after a
> month - people would notoriously walk with swollen fingers"
> 100% (^2)
>
> Regards
> Jaroslaw
>
>
>
> W dniu 2022-08-17 13:10:38 użytkownik Erik Aronesty <erik@q32•com>
> napisał:
>
> > you can stop talking about  the "security of the system" as meaningful
> > this has been discussed enough
> > if fees are not sufficient, clearance times increase and large
> stakeholders are incentivised to mine
> > in the best case, fees are sufficient
> > in the worst case, it degrades to proof of stake
> > i'm sure you can see how that's fine either way
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 6423 bytes --]

  parent reply	other threads:[~2022-08-18 15:44 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-17 13:43 jk_14
2022-08-18 15:29 ` Breno Brito
2022-08-18 15:44 ` Billy Tetrud [this message]
2022-08-18 20:49 ` 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  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=CAGpPWDbD5WQD2Nr6ngiSYtodTkij2N+1Aft5dn5yYePdQ1NC7w@mail.gmail.com \
    --to=billy.tetrud@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=jk_14@op$(echo .)pl \
    /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