public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: jk_14@op•pl
To: Billy Tetrud <billy.tetrud@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Pseudocode for robust tail emission
Date: Sat, 07 Jan 2023 19:52:47 +0100	[thread overview]
Message-ID: <174889786-7eefd505bbf223af3d3a1101c7c3044d@pmq3v.m5r2.onet> (raw)


> Anyways if it turns out that fees alone don't look like they're supporting enough security, we have a good amount of time to come to that conclusion and do something about it. 

The worst-case scenario is that the first global hashrate regression may take place in 2028.
Instead of the average price increase at least x2 every halving - the global hashrate may gradually decrease from that point. Again, it would be the worst-case scenario.

In my proposal you don't need to think about any calculations - just simple logic which we have right now. No hardcoded values and the free market in its finest - self-regulating the level of taxation of parties involved, but with opposite interests. And the mechanism would try to fix a global hashrate regression if appear.
In other words: let's be optimistic regarding fees, but with emergency mechanism built-in just in case.
The only drawback here is that the system is already running.

In my personal opinion avoiding long-term global hashrate regression is more important for store of value feature than the 21M schelling point (or trap...)




W dniu 2023-01-04 17:03:33 użytkownik Billy Tetrud <billy.tetrud@gmail•com> napisał:
> In Bitcoin "the show must go on" and someone must pay for it. Active [and/or] passive users 


I certainly agree. 


> or more precisely: tiny inflation


👍


> Right now security comes from almost fully from ~1.8% inflation.


Best I could find, fees make up about 13% of miner revenue. So yes, the vast majority of security comes from coinbase rewards. I assume you're implying that ~13% of today's security is not enough? I would love to see any quantitative thoughts you have on how one might determine that. 


Have there been any thoughts put out in the community as to what size of threat is unlikely enough to arise that we don't need to worry about it? Maybe 1% of the yearly government budgets of the world would be an upper bound on how much anyone would expect could realistically be brought to bear? Today that would be maybe around $350 billion. 


Or perhaps a better way to estimate would be calculating the size of the motivation of an attacker. For example, this paper seems to conclude that the US government was extracting a maximum of ~$20 billion/year in 1982 dollars (so maybe $60 billion/year in 2022 dollars if you go by CPI). If we scale this up to the entire world of governments, this seems like it would place an upper bound of $180 billion/year of seigniorage extraction that would be at risk if bitcoin might put the currencies they gain seigniorage from out of business. Over 10 years (about as far as we can expect any government to think), that's almost $2 trillion. 


Whereas it would currently cost probably less than $7 billion to purchase a 50% share of bitcoin miners. To eventually reach a level of $350 billion, bitcoin's price would need to reach about $800,000 / bitcoin. That seems within the realm of possibility. To reach a level of $2 trillion, you'd need a price of $4.3 million/bitcoin. That's still probably within the realm of possibility, but certainly not as likely.  If you then assume we won't have significant coinbase rewards by that point, and only 13% of the equivalent revenue (from fees) would be earned, then a price of ~$6 million would be needed to support a $350 billion and $34 million to support a $2 trillion security. I think that second one is getting up towards the realm of impossibility, so if we think that much security is necessary, we might have to rethink things. Its also quite possible, as the network of people who accept and use bitcoin as payment grows, that the fee market will grow superlinearly in comparison to market cap, which would make these kind of high levels of security more realistic. 


Anyways if it turns out that fees alone don't look like they're supporting enough security, we have a good amount of time to come to that conclusion and do something about it. 


> Deflation in Bitcoin is not 1:1 matter like in gold, for example...  Deflation in Bitcoin is more complex issue


It's helpful to keep our language precise here. Price inflation and deflation act identically in bitcoin and gold and anything else. What you seem to be talking about at this point is monetary inflation (specifically, a reduction in it) which of course operates differently on the machinery of bitcoin than it does in the machinery of gold or other things. Whereas my comment about you mentioning Gresham's law was specifically talking about price inflation, not the effects of the coin emission machinery in bitcoin. 




_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists•linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev






             reply	other threads:[~2023-01-07 18:53 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-07 18:52 jk_14 [this message]
2023-01-07 23:22 ` Eric
  -- strict thread matches above, loose matches on Subject: below --
2023-02-01 22:04 jk_14
     [not found] <mailman.9.1674388803.14535.bitcoin-dev@lists.linuxfoundation.org>
2023-01-22 14:13 ` John Tromp
2023-01-21 10:20 jk_14
2023-01-02 23:02 jk_14
2023-01-04 16:03 ` Billy Tetrud
2023-01-01 22:27 jk_14
2023-01-01 21:23 jk_14
2023-01-02  4:53 ` Billy Tetrud
2022-12-27 15:34 jk_14
2022-12-30 18:20 ` Billy Tetrud
2022-12-23 18:43 jk_14
2022-12-30 23:28 ` Peter Todd
2023-01-01 12:42   ` Alfie John
2023-01-18 20:58     ` Peter Todd

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=174889786-7eefd505bbf223af3d3a1101c7c3044d@pmq3v.m5r2.onet \
    --to=jk_14@op$(echo .)pl \
    --cc=billy.tetrud@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.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