public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: vjudeu@gazeta.pl
To: Billy Tetrud <billy.tetrud@gmail.com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>, ,
	"jk_14@op.pl" <jk_14@op.pl>, ,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary
Date: Fri, 19 Aug 2022 07:34:25 +0200	[thread overview]
Message-ID: <73904836-123affd52a139f11587a4971b0df5f07@pmq6v.m5r2.onet> (raw)

> 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.

Miners can game this system by moving their own coins in 100% fees transactions, just to produce more coins. You have one million BTC? No problem, just move them as fees, and you just created 100k BTC out of thin air, just because you are a wealthy miner. And even if that amount will be stolen, when some other miner will reorg your block, then still, miners will keep creating coins by moving them as fees, and the strongest miner will get the whole pot. And guess what: 100 blocks later you can reuse newly created 100k BTC to make another 10k BTC, so it will exponentially explode as (amountOfCoins*(1+0.1))^n function. And guess what: (1.1)^8 is 2.14358881. That means, after eight moves, you can double your coins, if you are a wealthy miner. And you can start with smaller amounts, to play it safe, but eventually, this system will degrade into "coin doubler after 800 blocks" or something similar.


On 2022-08-18 18:45:43 user Billy Tetrud via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
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




             reply	other threads:[~2022-08-19  5:34 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-19  5:34 vjudeu [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-08-18 20:22 [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary 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-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=73904836-123affd52a139f11587a4971b0df5f07@pmq6v.m5r2.onet \
    --to=vjudeu@gazeta.pl \
    --cc=billy.tetrud@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jk_14@op.pl \
    /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