Feedback-ID: i525146e8:Fastmail
Date: Sun, 17 Dec 2023 17:56:16 +0000
From: Peter Todd <pete@petertodd.org>
To: ArmchairCryptologist <ArmchairCryptologist@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <ZX82QKJCLLPMfHXl@petertodd.org>
References: <e5QWFNC21ZBNRZ_k0IJTSjTMm_7tvu8eu9seo84N4X87niVTfsDMv3I5l7YZgZ7zSXqNIlsGk-necWsDXsMd9AG8wnEBappboXMVsqygmiM=@protonmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="mYjkTX6EQJW8IVXP"
Content-Disposition: inline
In-Reply-To: <e5QWFNC21ZBNRZ_k0IJTSjTMm_7tvu8eu9seo84N4X87niVTfsDMv3I5l7YZgZ7zSXqNIlsGk-necWsDXsMd9AG8wnEBappboXMVsqygmiM=@protonmail.com>
Subject: Re: [bitcoin-dev] Addressing the possibility of profitable fee
 manipulation attacks
Precedence: list


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

On Sun, Dec 17, 2023 at 11:11:10AM +0000, ArmchairCryptologist via bitcoin-=
dev wrote:
> ** A possible solution, with some caveats **
>=20
> My proposed solution to this would be to add partial transaction fee burn=
ing. If 50% or more of transaction fees were burned, this should effectivel=
y curtail any incentive miners have for padding blocks with junk transactio=
ns in general, as it would both significantly reduce the amount of spent fe=
es they would be able to recoup, and also reduce the amount of benefit they=
 gain from the transaction fees being high. The burn rate would however nec=
essarily have to be less than 100%, otherwise miners would not be incentivi=
zed to include any transactions at all, and might as well be mining empty b=
locks.

Fee-burning solutions are easily bypassed with out-of-band fee payments.

If fee-burning was possible, I would have proposed it already as a way to
ensure there is always an incentive for miners to mine blocks. Unfortunatel=
y,
it does not work.

> Changing fee estimation algorithms across the board to not take historica=
l fee data into account, eliminating the long-term decaying fee effects obs=
erved after short-term flooding of high-fee transactions, would of course s=
ignificantly help prevent such attacks from being profitable in the first p=
lace without requiring any sort of fork. As such, I believe this should als=
o be done as a short-term makeshift solution. A less exploitable estimate c=
ould be made by limiting the algorithms to only use the current mempool sta=
te and influx rate, as well as possibly the estimated current blockrate and=
 the arrival times of recent blocks. Additionally, wallets could pre-sign a=
 number of replacement transactions spending the same UTXO(s) with graduall=
y increasing fees up to a maximum specified by the user, and automatically =
broadcast them in order as the state of the mempool changed. And I'm sure t=
here are additional strategies that could be used here as well to make the =
ecosystem more fee-optimal in general.

Yes, RBF needs to be used a lot more. CPFP is inefficient and wasteful, and
estimates are quite often wrong.

> Unfortunately, as long as some parties still use historic fee data for th=
eir fee estimation, the attack could still be effective up to a point. Paym=
ent providers like BitPay for example currently specify that you need to us=
e a historically high fee for the initial transaction for it to be accepted=
, and does not recognize replacement transactions that bump the fee.

BitPay is just a garbage payment processor. Possibly intentionally so, with=
 the
aim of getting big block policies introduced.


BTW note how if mining pools are intentionally flooding the network to incr=
ease
fees, mining pools such as Ocean that filter out fee-paying transactions th=
at
are part of the (possible) attack actually contribute to this problem by
reducing the cost of the attack.

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

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

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmV/Nj4ACgkQLly11TVR
LzeaVRAAs/H6oN5nLJ6QZ5D8k83Cyqnr1vfTpWcDNzfRjTUpcg73PAqFGR66pffK
Nz25scMCaaplbQh9t75br/RuEZrW+I3xhW2YSDDy7ev5SbKP5Sr1dc6E83vnYo+Y
O6bt5xezKItheSBOehNqBu8rkRbqt7Nq2PqQYv/K6uUlQDJQ2445WEr87+RmNs4Y
bqRtX6NTxilA42ZTs727OgwLZcH2ftEk03RIdHxIf1sjDSXyC95a7d7WNCQkDl37
NxmOjrN8djgNYkb3DEoR62pehaCjHm+Ivi0I9CZt/SgFJshCBwsZ7ubFL5YcIfVx
uepp7rGRH7a8L9HOjRX+KIJPpJye/S0Y4dt+l05taXPZJZsai+JV84k+0vn7aoT7
UDzx4ew79kmrGxuwU21ZwH19cSESKTnaB44EQJdn9IZnxrMZ/kgmvrvBIjH+YRsS
rzMm78+LF5XFETMfiq7Py9lPre+umWlJSQt0J9l2KHdjo5vxVr9R0//+OyMU2WVP
haNDV4V1GrKw8cJHEulrkC60EQmYsXCKXDKPFDEg8cgtvyDZME8nZAwoXOK8Q1GC
IBrSbfABZPRgWMC848Dje6WUUCBSQmSPgWznvLq9ocaDKylq6txXV54e+CW0MZtY
+cRqgV9KGFxmelcyngUklRsO2D2OxY8OrXLEviAq+k044gSV2DE=
=UteR
-----END PGP SIGNATURE-----

--mYjkTX6EQJW8IVXP--