Feedback-ID: i525146e8:Fastmail
Date: Sun, 10 Jul 2022 13:27:05 -0400
From: Peter Todd <pete@petertodd.org>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <YssL6VL9y6EwyBjr@petertodd.org>
References: <D50AEC8C-4EEC-4C17-8626-87C651F1AA66@voskuil.org>
 <6xuj-ljJ9hvME-TIgWHmfPpad4aJ-1zTYSH1NBuFL_gi-6hJHMayWLEAhcEyw_lqmkR24ee8uMIAH6n4TDguk_5fJ8och99Em3m5y1R6brE=@protonmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="mPLwxQosmUnrKIKt"
Content-Disposition: inline
In-Reply-To: <6xuj-ljJ9hvME-TIgWHmfPpad4aJ-1zTYSH1NBuFL_gi-6hJHMayWLEAhcEyw_lqmkR24ee8uMIAH6n4TDguk_5fJ8och99Em3m5y1R6brE=@protonmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary
Precedence: list


--mPLwxQosmUnrKIKt
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Jul 09, 2022 at 09:59:06PM +0000, ZmnSCPxj wrote:
> Good morning e, and list,
>=20
> > Yet you posted several links which made that specific correlation, to w=
hich I was responding.
> >
> > Math cannot prove how much coin is =E2=80=9Clost=E2=80=9D, and even if =
it was provable that the amount of coin lost converges to the amount produc=
ed, it is of no consequence - for the reasons I=E2=80=99ve 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.
>=20
> To clarify about censorship resistance and perpetual issuance ("tail emis=
sion"):
>=20
> * 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 min=
er 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 f=
rom the censorship has to be proportionately larger than in the first situa=
tion.

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

https://petertodd.org/2016/mit-chainanchor-bribing-miners-to-regulate-bitco=
in

The Chain Anchor model was to simply straight up bribe and coerce miners in=
to
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 er=
odes 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 sec=
ure.

> But the block subsidy is still issued whether or not coins being moved ar=
e 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 valuabl=
e.
Not some piddling transaction fees.

> Thus, we should instead prepare for a future where the block subsidy *mus=
t* 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-av=
g,
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 n=
eed
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 c=
oin
done it?

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

--mPLwxQosmUnrKIKt
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmLLC+YACgkQLly11TVR
Lzf+kg//fpIkpY2KhXPDlj1B2qDS02/tEMt74tr9a+ZpeoIQUdaXJyaag+xefMpv
vaLCLymQpKr1PnuRhKi0n6K3FeqkGwPUW2XQSHjBjlkOiS6SSnyei8W4uG+qt46Y
gWQksFJ6aAbLDRah5mtX5OiSo3X7HeQOx6wA944HyKQDHru8U2c6EUtTm1WiLHSo
NS49eHdtdJAsvNsTPud/sxDvNrMQd2rzSp2NYnLXhlneG/HPJ+sjE8ocMyhdCNUj
vrehr32+C5MMOlFCPLtLfmHNBaOfiTdJoN2Y65u4/lCqsKxe5izN/Hby7GI8XZWV
ca1X5Pu2Q5wwMwL4frLHgACScEngwAtliqzh0jvpUV1Jk2n0Bzb7Xud+kmXhft4i
x5zBTuDFIVSr032yaBd+UU8Dd2VT1TYsaoPm+mg3DSDnsA+aD6+uqPOGFIyQAO4l
+pqRvq+i//TGEKqivVZnWDp6AUFaqF0biVpyEKKy2hayYuWZoVpzAm7S8Nyblmqp
e/WjesPYhkJoB6FuwuyQ/eDJ/nkkgFh2F2Z1NCooM0EwTcH0dhKkh3PODHiKboyy
a4azcieVjbYXJg90M4PWQS06/tgaU76eb2u4m7GrtB4JqM96zsF3gciIzIfTs+h9
5vmYFdj1/VsaFueMG95RKPn2QIF4jffwRDVCdZR9cioe/vuw3vE=
=lXav
-----END PGP SIGNATURE-----

--mPLwxQosmUnrKIKt--