public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd•org>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary
Date: Sun, 10 Jul 2022 13:27:05 -0400	[thread overview]
Message-ID: <YssL6VL9y6EwyBjr@petertodd.org> (raw)
In-Reply-To: <6xuj-ljJ9hvME-TIgWHmfPpad4aJ-1zTYSH1NBuFL_gi-6hJHMayWLEAhcEyw_lqmkR24ee8uMIAH6n4TDguk_5fJ8och99Em3m5y1R6brE=@protonmail.com>

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

On Sat, Jul 09, 2022 at 09:59:06PM +0000, ZmnSCPxj wrote:
> Good morning e, and list,
> 
> > Yet you posted several links which made that specific correlation, to which I was responding.
> >
> > Math cannot prove how much coin is “lost”, and even if it was provable that the amount of coin lost converges to the amount produced, it is of no consequence - for the reasons I’ve already pointed out. The amount of market production has no impact on market price, just as it does not with any other good.
> >
> > The reason to object to perpetual issuance is the impact on censorship resistance, not on price.
> 
> To clarify about censorship resistance and perpetual issuance ("tail emission"):
> 
> * Suppose I have two blockchains, one with a constant block subsidy, and one which *had* a block subsidy but the block subsidy has become negligible or zero.
> * Now consider a censoring miner.
>   * If the miner rejects particular transactions (i.e. "censors") the miner loses out on the fees of those transactions.
>   * Presumably, the miner does this because it gains other benefits from the censorship, economically equal or better to the earnings lost.
>   * If the blockchain had a block subsidy, then the loss the miner incurs is small relative to the total earnings of each block.
>   * If the blockchain had 0 block subsidy, then the loss the miner incurs is large relative to the total earnings of each block.
>   * Thus, in the latter situation, the external benefit the miner gains from the censorship has to be proportionately larger than in the first situation.

Now let's look at an actual, real-world, attempt to censor Bitcoin via mining:

https://petertodd.org/2016/mit-chainanchor-bribing-miners-to-regulate-bitcoin

The Chain Anchor model was to simply straight up bribe and coerce miners into
only accepting compliant transactions. That's only effective when a large % of
miners actually do that - if a small % do the effect on confirmation time is
miniscule. Obviously, censoring transactions is a significant threat to the
value of Bitcoin - and thus all your Bitcoin-only hashing equipment.

So how do you make a Chain Anchor attack cheaper? By reducing total mining
reward, and making it tied to transaction volume rather than the value of
Bitcoin as a whole.

> Basically, the block subsidy is a market distortion: the block subsidy erodes the value of held coins to pay for the security of coins being moved.

The block subsidy directly ties miner revenue to the total value of Bitcoin:
that's exactly how you want to incentivise a service that keeps Bitcoin secure.

> But the block subsidy is still issued whether or not coins being moved are censored or not censored.
> Thus, there is no incentive, considering *only* the block subsidy, to not censor coin movements.
> Only per-transaction fees have an incentive to not censor coin movements.

The strongest incentive not to censor is because it'll keep Bitcoin valuable.
Not some piddling transaction fees.

> Thus, we should instead prepare for a future where the block subsidy *must* be removed, possibly before the existing schedule removes it, in case a majority coalition of miner ever decides to censor particular transactions without community consensus.
> Fortunately forcing the block subsidy to 0 is a softfork and thus easier to deploy.

Absolutely not.

The historical reality of transaction fees is they've had huge swings, about
10x more volatile than total miner revenue. In the past three years they've
ranged from $8.4 million USD/30-day-average to as little as $140k/30-day-avg,
with the current amount being $370k/30-day-avg. That's a 60x difference.

Meanwhile miner revenue has ranged from $60 million/30-day-avg to $9
million/30-day-avg, a 7x difference.

https://www.blockchain.com/charts/fees-usd-per-transaction

We want mining to be is a boring, predictable, business that anyone can do,
with as little reward as possible to larger scale miners. That's what you need
for maximal decentralization. Making mining a sophisticated business reduces
the pool of entities that can profitably compete in it, and increases their
visibility to government regulation.

Additionally, we want mining to be predictable to avoid having large gluts of
unprofitable mining equipment laying around: mining equipment that could be
used to attack Bitcoin. Fee revenue is obviously doing a much worse job of
achieving that goal than subsidy revenue.


If transaction-fee-only mining was such a good idea, why hasn't any other coin
done it?

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2022-07-10 17:27 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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
  -- 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-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: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=YssL6VL9y6EwyBjr@petertodd.org \
    --to=pete@petertodd$(echo .)org \
    --cc=ZmnSCPxj@protonmail$(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