Feedback-ID: i525146e8:Fastmail
Date: Mon, 22 Jan 2024 22:52:01 +0000
From: Peter Todd <pete@petertodd.org>
To: Murch <murch@murch.one>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Za7xkUsoeACMv6Fw@petertodd.org>
References: <Zalsq+Nq7RRr/CAR@petertodd.org>
 <9a89eca8-61fd-4156-825d-c9b718dc3034@murch.one>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="sh/rvim7uikMYwTI"
Content-Disposition: inline
In-Reply-To: <9a89eca8-61fd-4156-825d-c9b718dc3034@murch.one>
Subject: Re: [bitcoin-dev] One-Shot Replace-By-Fee-Rate
Precedence: list


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

On Mon, Jan 22, 2024 at 01:12:45PM -0500, Murch via bitcoin-dev wrote:
> Hi Peter,
>=20
> On 1/18/24 13:23, Peter Todd via bitcoin-dev wrote:
> > Reposting this blog post here for discussion:
> >
> > https://petertodd.org/2024/one-shot-replace-by-fee-rate
>=20
> I saw your proposal mentioned on Stacker News and read it with interest. =
In
> response, I described a replacement cycle that can be used to broadcast t=
he
> same five transactions repeatedly:
>=20
> https://stacker.news/items/393182

So if this does in fact work - I haven't actually tested it - the root prob=
lem
here is not replace-by-fee-rate, but rather our current replace-by-fee rule=
s:
in step 7 you've clearly replaced a more desirable, high fee-rate, transact=
ion
that will be mined soon with a low fee-rate transaction that will not be.
That's obviously not incentive compatible for miners, for the same reason t=
hat
replace-by-fee-rate generally is incentive compatible.

I had incorrectly thought we had gotten rid of those cases... But looks like
the definition of BIP-125 Rule #2, "The replacement transaction may only
include an unconfirmed input if that input was included in one of the origi=
nal
transactions.", is not sufficient because you can combine unconfirmed inputs
=66rom two different replaced transactions, making a resulting transaction =
that
is less valuable to miners than one of the replaced transactions.

IIUC Suhas has a draft fix here that would solve this issue: https://github=
=2Ecom/bitcoin/bitcoin/pull/26451

An even simpler fix would be to just require that all unconfirmed inputs in=
 a
replacement come from the *same* replaced transaction. That would make cert=
ain
rare, but economically viable, replacements infeasible. But it would defini=
tely
fix the issue.

> The gist is that by using two confirmed inputs and five transactions, you
> can use RBFr to reduce the absolute fee while raising the feerate to top
> block levels, then immediately use the current RBF rules to introduce a
> high-feerate transaction that beats the RBFr transaction but is hampered =
by
> a low-feerate parent and not attractive for mining, then use RBF to repla=
ce
> its low-feerate parent, then use the RBFr transaction again to reduce the
> absolute feerate. Due to the asymmetric replacements, the same transactio=
ns
> can replace each other in that order in every cycle. Please refer to the
> linked write-up for details, I=E2=80=99ve included weights, fees, and a t=
ransaction
> graph to make my example comprehensible.

BTW do you mind if I reproduce those graphics, with credit, to explain the
issue? I have a few places where I could make use of it, eg the
replace-by-fee-rate post itself.

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

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

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmWu8YIACgkQLly11TVR
LzfqeRAAhOsWablFP/QAA6zjZtTgw9k6SowqOpGjCHXOOPbKv7bMJ2UqDg3wnbCF
BKJNwLc+SRhVtLdT64uCbGi5L1sg1TvCf+hsoSWnwjhuvKX93br5bEc+VYWu+l61
np4y4v7YnHbrFMb34wYOmmUXLeW2lbhXsZaz51OoNfoSuVdG5ZGWPrqSFERK2p6n
hUEDqOsrYHa6A4PRwFt3LJR16s2nZp1Qq3ls3byFvF7kgcZx21/V29lDMqzwOG8B
0CTuWO8YdMCA755UO/wpTLR2m+XdTTDht0G5klF1HU6oFj+WXZHOzPxHVNoRBGyX
7uUCEfdUbjsEnuqeG/eGY04PL+eEIWIwo0MxjW4qdnOsfK+YM7Q59IK691GYVs6v
Rya7xdLfWe8QkVWxpC+9/d8C3sa+a3l/S7Pk/x1cqzlpP17ZXUHQE6PIg2K/j2/3
4h43Rd2l7dCeaMq9p/bL2EEx1+ZT0gZpFYIXK+yMtSrlwDXKd9jzj700plfKxP7G
b3nfnJbIKKho+rXVIB1Ns11CVfDQJuXdZm6znkvjKUK+FFQSgaYHz/8E6K8JM7jo
rBOJR8PI5okQ9JLs0pTb+whoIkSLwFRYhjsyLuhx2W1uMU8GAmClca34LqIzMt3o
xF1AExl238TyOOIV/WWy9efsR0ROpUG+h6RWOeVbvnJfBRjWq9k=
=09en
-----END PGP SIGNATURE-----

--sh/rvim7uikMYwTI--