Feedback-ID: i525146e8:Fastmail
Date: Thu, 27 Oct 2022 11:00:16 -0400
From: Peter Todd <pete@petertodd.org>
To: Greg Sanders <gsanders87@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Y1qdALo0sadzr/QS@petertodd.org>
References: <Y1nIKjQC3DkiSGyw@erisian.com.au>
 <CAB3F3DvXkmd6+nG=eXaiOK9MJr8RtiQ4pnMWN+vW0pMJKQbQ=Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="ktemXg2LQ/4S/cEV"
Content-Disposition: inline
In-Reply-To: <CAB3F3DvXkmd6+nG=eXaiOK9MJr8RtiQ4pnMWN+vW0pMJKQbQ=Q@mail.gmail.com>
Cc: Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] On mempool policy consistency
Precedence: list


--ktemXg2LQ/4S/cEV
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 27, 2022 at 09:49:48AM -0400, Greg Sanders via bitcoin-dev wrot=
e:
> So there is some precedence to including an option that protocol devs don=
't
> find useful, then removing it N years later to make sure it doesn't impact
> compact blocks.

I think the lesson there is we're willing to remove options that are
ridiculous. Replacements are widely used, and downright essential in high-f=
ee
situations.

> Peering into the "precedence" lense, I think this does lend itself to the
> theory that the transition should be as uniform as possible to avoid
> degradation of fast block propagation. If not removing options(which is
> deemed user hostile by a number of folks including me), then at least for=
 a
> flag day switchover.

Re: compact blocks, note that RBF is a special case: for the sake of
reconstruction, it'd make sense to temporarily cache transactions have have
been replaced rather than discarding them entirely, in case a prior version
gets mined. Irregardless of policy this will happen occasionally simple due=
 to
propagation delays. Equally, if we cached transactions that we rejected due=
 to
policy, that'd help with reconstruction success in the event that policy is
changing.

Anyway, since the compact blocks implementation efficiently deals with the =
case
where miners have policy that differs from most nodes, by immediately
forwarding missing transactions, I don't think the occasional full-rbf
replacement is going to have much impact. The nodes that had full-rbf disab=
led
will forward the tx to their peers directly, and then the subset of full-rbf
disabled peers will do the same again. So long as the network has a mix of =
both
types, and they're interconnected rather than in clusters, the latency impa=
ct
should be minimal.

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

--ktemXg2LQ/4S/cEV
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmNanPEACgkQLly11TVR
LzcZvw//S+09G43NeLlI2uTtGPZNTMG1wlj/40Q4escc3/bOyqCnlmBkR8bezvrx
6i7s9UwY+bwtfQKtrNX3Z5pTGN/QsMHSkrRI0I7F+81v4/4TCFcX8FPQTc0Ebcqw
i9XY6PRJGDYJpeWatNHiMWO4S//ES8Gmd7Ug7XjtzjGgEbJ4jEP+V4+c17e13wp6
yQvuM4q6nfKUV0jEMB1oTrmv+L5dECRVQVFQIlSqYIkWTOU9bzCWsxmT+6yzhUNO
pwOJ6afkiqzohVZZKlvbUIDubGHNEfoRcKw1gmiYJuoxNv55COBMDgYSaE+606hH
64ZIkp9J4EaE4Tqlz244nRDPs9CkahUddQSk3iAe7Ff7FvJnNMsgy+42oFaRCglH
SVSfiIJfWvChC4p+3N0oiQqruTabPVD8gX7+Zdu3KF97AKTPIhM1MySkEPIcRfXd
tT0gn8y34ut+jxh3djf3qOY0/pHwc9CI3N2Vsw22DpUeoMcaDuaz015Tv419N52Y
st6nci6d6ds9MqfVElqPCU3f6kkUtfNZdSlTm09CESWL71RmNRYdyK8lI9MejI+M
gGmfsulCk03sxNRF5cAXhXtwjc8Q48WEHmavria3r7goTrtf6w+bLp7fRjTDgXq3
1sl1+DEiUiEzwxCO0KDyH9cxoCFA+YqcR52H2P/WI1jwInyLoK0=
=MIR+
-----END PGP SIGNATURE-----

--ktemXg2LQ/4S/cEV--