Feedback-ID: i525146e8:Fastmail
Date: Mon, 11 Jul 2022 17:53:37 -0400
From: Peter Todd <pete@petertodd.org>
To: Bram Cohen <bram@chia.net>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Ysyb4T/36oXeAH+z@petertodd.org>
References: <CAHUJnBDYDbgr3C158o7c6_XXdG+kqJruFo=od_RmPFk_GS0udw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="eqlpffpinTU5x1UZ"
Content-Disposition: inline
In-Reply-To: <CAHUJnBDYDbgr3C158o7c6_XXdG+kqJruFo=od_RmPFk_GS0udw@mail.gmail.com>
Subject: Re: [bitcoin-dev] Security problems with relying on transaction
 fees for security
Precedence: list


--eqlpffpinTU5x1UZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 11, 2022 at 11:12:52AM -0700, Bram Cohen via bitcoin-dev wrote:
> If transaction fees came in at an even rate over time all at the exact sa=
me
> level then they work fine for security, acting similarly to fixed block
> rewards. Unfortunately that isn't how it works in the real world. There's=
 a
> very well established day/night cycle with fees going to zero overnight a=
nd
> even longer gaps on weekends and holidays. If in the future Bitcoin is
> entirely dependent on fees for security (scheduled very strongly) and this
> pattern keeps up (overwhelmingly likely) then this is going to become a
> serious problem.
>=20
> What's likely to happen is that at first there will simply be no or very
> few blocks mined overnight. There are likely to be some, as miners at fir=
st
> turn off their mining rigs completely overnight then adopt the more
> sophisticated strategy of waiting until there are enough fees in the
> mempool to warrant attempting to make a block and only then doing it.
> Unfortunately the gaming doesn't end there. Eventually the miners with
> lower costs of operation will figure out that they can collectively reorg
> the last hour (or some time period) of the day overnight and this will be
> profitable. That's likely to cause the miners with more expensive
> operations to stop attempting mining the last hour of the day preemptivel=
y.
>=20
> What happens after that I'm not sure. There are a small enough number of
> miners with a quirky enough distribution of costs of operation and
> profitability that the dynamic is heavily dependent on those specifics, b=
ut
> the beginnings of a slippery slope to a mining cabal which reorgs everyone
> else out of existence and eventually 51% attacks the whole thing have
> begun. It even gets worse than that because once there's a cabal
> aggressively reorging anyone else out when they make a block other miners
> will shut down and rapidly lose the ability to quickly spin up again, so
> the threshold needed for that 51% attack will keep going down.
>=20
> In short, relying completely on transaction fees for security is likely to
> be a disaster. What we can say from existing experience is that having
> transaction fees be about 10% of rewards on average works well. It's enou=
gh
> to incentivize collecting fees but not so much that it makes incentives g=
et
> all weird. 90% transaction fees is probably very bad. 50% works but runs
> the risk of spikes getting too high.
>=20
> There are a few possible approaches to fixes. One would be to drag most of
> east asia eastward to a later time zone thus smoothing out the day/night
> cycle but that's probably unrealistic. Another would be to hard fork in
> fixed rewards in perpetuity, which is slightly less unrealistic but still
> extremely problematic.
>=20
> Much more actionable are measures which smooth out fees over time.

Note that a tricky thing here is that smoothing out fees is made difficult =
by
the fact that users can by-pass the fee system by including anyone-can-spend
outputs in their transactions. Or worse, by simply paying large miners
out-of-band to get their txs confirmed. So any smothing scheme that tries to
smooth the market-based fees we already have will fail.

The only type of fee-smoothing scheme that is feasible is to smooth an enti=
rely
separate category of fees that are made mandatory. For example, you could
achieve the economic impact of inflation by having a fixed value*time based=
 fee
that goes to timelocked anyone-can-spend outputs in the coinbase to push the
fee forward to other miners.

Doing this is of course a gigantic accounting headache, and problematic for
existing L2 protocols, because you are reducing the value of txouts as they=
 age
(demurrage). But at least it's a soft-fork.

Interestingly, if you look at transaction fees in blocks right now, people
regularly pay far higher transaction fees than necessary. There seem to be a
bunch of high value users, eg $1 million txs, without terrible fee estimati=
on.
And I suspect the reason why this happens is simply that for a $1 million t=
x,
overpaying 100x with a $100 tx fee is irrelevant. Of course, this is also a
problem from the re-org point of view...

> Having
> wallets opportunistically collect their dust during times of low
> transaction fees would help and would save users on fees.

You're assuming wallets will even have dust to collect. With widespread use=
 of
Lightning that will likely not be true. Indeed, with sufficiently efficient=
 L2
solutions it's really unclear as to how much demand there will be for block
space.

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

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

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmLMm94ACgkQLly11TVR
LzdbCRAAqqVksSkLJNycAb9/nbVLx7vjVv+zhd7txqiQp+urPQirQrx9NtDCEI8t
51x/XuVKXQvdN+uaIVcDB6jhK+3bFklSKB5Bv2a28czyJvaiynqkiZTGnZh2mULW
jA4veGrrplVA97QDxWalp2C6S1EO4HFYDEgHXFDm86/TjZHxf1aLaxFl+zr+9pe9
SXxeA42kCARSefcd+347Z5hAKg60+6kn7GZP4x/5SO7e+TjANddpzGdVw4j5ILbZ
RwaIn9JD8IKQA+A5OiP8pBKQ0jnJcQyfYI5dtUiPPZ1PSo/nMU1rCxsgDlV3cbUg
WSgePWIHNFL9L/Ua1KR3+hfwuUMOUH8/T7E4aSGQ8YGQRcwrlaIlTF7w9CdHjEAH
OLHEh9PW3efun8UmFcAqccsuB8bf8HRKWr/sAYeY5GsNaR5jIAY6MuUuS2lALyBW
gsZaMwgzMoxVHerQBGSWgDEPALU2l/ci1yD1Ei7UvGbcdyLcE8pHHPXSOUDjpQ81
z6/PyzIQLGfPozciU/U+5T6ZVKgkhqaDHimCwcvzm03KuROeYIjMyHCaYZmkmXlR
WzZlx6VMsP9Ial08UXNalPIglRhUI/B4bWZSvzXl25XbOueqFTGnxU5QB2dWinaV
Q8bZiPXYShiPeRH1K0rNc8bRgTWmfCTKSh/Htw1iXQZuJKeioE4=
=Ehd6
-----END PGP SIGNATURE-----

--eqlpffpinTU5x1UZ--