Feedback-ID: i525146e8:Fastmail
Date: Mon, 31 Oct 2022 13:51:10 -0400
From: Peter Todd <pete@petertodd.org>
To: email@yancy.lol,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Y2ALDu36tMQxVr/i@petertodd.org>
References: <Y1nIKjQC3DkiSGyw@erisian.com.au>
 <CAFp6fsFm06J2G1=3ojQvcL9gbEbQ41C4rmf3=Jkm9Qm0VBhhKw@mail.gmail.com>
 <CAB3F3Dt=2hDXXw6Jz9QwnotkNLyGdZn9GZLHFXu0Dnyz3tsc0w@mail.gmail.com>
 <23dac89d36c356b9266db07e09c2de8e@yancy.lol>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="UiZssDDyd9AgECKb"
Content-Disposition: inline
In-Reply-To: <23dac89d36c356b9266db07e09c2de8e@yancy.lol>
Cc: Greg Sanders <gsanders87@gmail.com>
Subject: Re: [bitcoin-dev] On mempool policy consistency
Precedence: list


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

On Mon, Oct 31, 2022 at 06:21:08PM +0100, yancy via bitcoin-dev wrote:
>=20
> Protocol Devs,
>=20
> After reading through this email thread and BIP125, I'm curious if non-rbf
> nodes will relay full-rbf transactions and vice versa.  That is to say, if
> only one non-rbf node exists on the network, however, every other node
> implements full-rbf, will the transaction still be propagated?  IE can we
> always guarantee a path through the network for either transaction type no
> matter what the combination of network policies are?

1) There are nodes that signal full-rbf, and preferentially peer to each ot=
her,
thus ensuring good transaction propagation. The most recent patch to implem=
ent
this is: https://github.com/bitcoin/bitcoin/pull/25600

There's enough peers running full-rbf that the last time I started up a new
node on a fresh IP address, it happened to have a peer relaying full-rbf
replacements to it. And of course, if people want full-rbf to work more
reliably, it's very easy to just run some nodes with a large number of outg=
oing
peers. Changing the hard-coded 8 outgoing peers to, say, 800, isn't very ha=
rd.

2) There's nothing special about a "full-rbf transaction" other than the fa=
ct
that it's replacing a previously broadcast transaction that didn't signal
replacement. There is not consensus over the mempool, so in certain cases
non-full-rbf nodes will in fact broadcast replacements when they didn't hap=
pen
to receive the "first" transaction first.

The latter makes testing full-rbf a bit problematic, as if you don't take
special measures to ensure good propagation a small % of the time the
"replacement" transaction will in fact be the one that gets gets mined.

> > Does fullrbf offer any benefits other than breaking zeroconf
> > business practices?  If so, what are they?
>=20
> I think AJ mentioned this earlier, but adding more configuration options
> always increases code complexity, and with that, there is likely more
> unforeseen bugs.  However, there is a section of network participants that
> rely on both types of transaction policy, so from my limited view-point, =
it
> seems worth accommodating if possible.

Since all the machinery to do replacemnt already exists, adding a full-rbf
config flag is particularly trivial. It requires just a single line in the
mempool code.

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

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

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmNgCwwACgkQLly11TVR
LzcKmxAAjaTvECWJgd5PSABejnf86zoGMJQ4mBt5QgF1i+i8KBJ3MI//ISFW6uwM
lrO9rnfGpo8rzr7fqav+stQhhGJnR2ZizSlQ0rkDFPNbOwQijPGC9g4T74EQgH66
i3VVTqFo+zo/tYgY8VnyHn5CZ1C66rTPfRFxpuVJzYcTMrjTqZcNeabtbxhcKQTP
ilvLSpJh5PY+bTGr8BgMYDwt2glEQ4j/Sh6dq7TtMSMhRM4bpErE9eC7tZqoG4Tz
OZnYpngX0zDKuqX/RnvpLNGCGcvR5hKLl/RzNZigZWKzIe/vl2xNHIw+Vl7qfHl3
1OlBRYWYYWxJzlnqrmRujuVkL8ywa8zvxfTdTb6+BoKUDI/r6yAFoUucpUs5mJcJ
/9cKBGnKRTG6C03YQaUb9Gw5SsqGz1KZVkyYWlIrP7B3KaoLklEK9QAp4kWFgBBo
3abOBPYTfnHu0oSBmepXhHPzKoHyda9cLJAAaKEI41+0c3/kt2kLH9H5NbkwDYtJ
vH+ffh6PTLicvbesEhbSpmeOtKjQTqUtuD3nAL8udt3lOyyfqSNrsUpGjb5nNbcc
ataeF5AC+n4MafZuJM7dcQC/8VrsTggUXtNRTuCBtXHMhTVTGiUEwYRSLUgOWBMO
T81kgh7fYBZftfmbS5grV69Wf98BQ1Y2zzSM76oDQdiNyG9OpDc=
=5ySU
-----END PGP SIGNATURE-----

--UiZssDDyd9AgECKb--