Feedback-ID: i525146e8:Fastmail
Date: Sun, 19 Jun 2022 06:42:15 -0400
From: Peter Todd <pete@petertodd.org>
To: alicexbt <alicexbt@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Yq79h7biyvbu4ifi@petertodd.org>
References: <CALZpt+GOh-7weEypT9JrzcwthZJqHOfj7sf9FMuqi5_FZv0g7w@mail.gmail.com>
 <gmDNbfrrvaZL4akV2DFwCuKrls9SScQjqxeRoEorEiYlv24dPt1j583iOtcB2lFrxZc59N3kp7T9KIM4ycl4QOmGBfDOUmO-BVHsttvtvDc=@protonmail.com>
 <CALZpt+FJ-R9yCoMLP=Vcxk1U7n=-LKHUGctFZj0K-vTMsz==ew@mail.gmail.com>
 <RJEFmrnjbzKQCBr4L7ebwBLzg7QHGXlaE19zj6jfkxL6xjfodgbfssZBQSYxm783Y4X5awuhL9Gj8IaBc4npE2oh3d1xoudKTrSsJ-dk0VQ=@protonmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="3xoXbsCseTv8/AsP"
Content-Disposition: inline
In-Reply-To: <RJEFmrnjbzKQCBr4L7ebwBLzg7QHGXlaE19zj6jfkxL6xjfodgbfssZBQSYxm783Y4X5awuhL9Gj8IaBc4npE2oh3d1xoudKTrSsJ-dk0VQ=@protonmail.com>
Subject: Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s
 security
Precedence: list


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

On Fri, Jun 17, 2022 at 04:54:11AM +0000, alicexbt via bitcoin-dev wrote:
> > If they'reparties interested in implementing more RBF policy options in=
 Bitcoin Core, I think they're free to propose suchchanges and invest the e=
ngineering effort to do so. If you're interested in advancing the state ofp=
olicy options in Bitcoin Core, there are a lot of interestingresourcesavail=
able and communities toencourage you in the learning process to contribute =
to the codebase [6].
>=20
> Thanks for sharing the link. I would love to see 5 RBF policies available=
 to use in bitcoin core. I have already tried experimenting with a few on r=
egtest and will try to open pull request if there are enough people interes=
ted to test it on other chains (testnet3, signet, mainnet)

I don't think more RBF policies in Bitcoin Core helps much. RBF policies ar=
en't
very useful in isolation: unless you're getting your txs to other nodes/min=
ers
via special peering efforts, the only reason to run an uncommon RBF policy =
is
to accomodate local software with obsolete expectations about mempool behav=
ior.
That's why my full-RBF patch advertised a special service bit, and did
preferential peering with other nodes advertising that service bit.

Bitcoin Core isn't going to do that for every RBF policy. So there's no rea=
son
we should try to accomodate a bunch of them.

I can understand a -fullrbf flag from a political point of view, in the pro=
cess
of enabling full-RBF all the time. But there's no reason to go beyond that.

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

--3xoXbsCseTv8/AsP
Content-Type: application/pgp-signature; name="signature.asc"

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

iQEzBAEBCgAdFiEEFcyURjhyM68BBPYTJIFAPaXwkfsFAmKu/YIACgkQJIFAPaXw
kfsD3gf8CqrFZPiB/OdI5W91LTK5JO4EQE5cTCSkjSPn9+GxG9UPtDTYdTp4bPMl
HCavyNJttbXPbB4Q8R/e40iAyAZgS+h6BfhT1UrGZ7+DZO3sT6t77LeFmSR+vFRE
taL8t0Jx37RLGNCOEJFU3KqMmxX9akRUnjgaGy3FuT1pAIsjqHgLtzkCePvAh+UU
xsdxV1Cy/HPYk/epgofVwDfk9Ca/NOqseG3oXKIN0C7lsV1Fr70GOQFbmGcgB1Hb
fVCcz8P1hn8KXDQuNxTo5w60luQ89ImtT2g6hDQxaAxBc6D/OqiveLIZjzcGuE4P
k7x8KOgqlSmc6sIodzpPRyT2d+RZ9A==
=oh0N
-----END PGP SIGNATURE-----

--3xoXbsCseTv8/AsP--