Feedback-ID: i525146e8:Fastmail
Date: Fri, 4 Nov 2022 22:35:03 -0400
From: Peter Todd <pete@petertodd.org>
To: Suhas Daftuar <sdaftuar@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Y2XL16AkpH+xNi9B@petertodd.org>
References: <Y1nIKjQC3DkiSGyw@erisian.com.au>
 <CAFp6fsFm06J2G1=3ojQvcL9gbEbQ41C4rmf3=Jkm9Qm0VBhhKw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="Gdsin4sPJgWt7i6w"
Content-Disposition: inline
In-Reply-To: <CAFp6fsFm06J2G1=3ojQvcL9gbEbQ41C4rmf3=Jkm9Qm0VBhhKw@mail.gmail.com>
Subject: Re: [bitcoin-dev] On mempool policy consistency
Precedence: list


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

On Mon, Oct 31, 2022 at 09:02:02AM -0400, Suhas Daftuar via bitcoin-dev wro=
te:

Sending this email for the sake of repeating a point I made on GitHub for t=
he
mailing list audience:

> AJ,
>=20
> Thanks for the thoughtful post. I think your observations about how we vi=
ew
> mempool policy in the Bitcoin Core project, and how that seems to be
> changing in the discussions around `-mempoolfullrbf`, are on-point and
> provide a helpful baseline for considering future policy changes.

<snip>

> To those who argue for making fullrbf a default policy on the network (or
> even just offering a flag for users to enable fullrbf), I pose this
> hypothetical: suppose we deploy the v3 transaction policy proposal (which=
 I
> hope will happen in the near future).  That policy would restrict the ways
> that outputs of a v3 transaction can be spent while the transaction is
> unconfirmed, including by limiting the number and size of descendants that
> such a transaction can have, and limiting the types of unconfirmed
> ancestors that can be included.  Suppose in a few years someone proposes
> that we add a "-disable_v3_transaction_enforcement" flag to our software,
> to let users decide to turn off those policy restrictions and treat v3
> transactions the same as v2, for all the same reasons that could be argued
> today with fullrbf: miners might earn more revenue if we allowed multiple
> descendant v3 transactions; it's illogical for the recipient of a v3
> transaction to believe what is a fundamentally unenforceable promise of a
> sender to not issue more high value children that descend from an
> unconfirmed transaction; it's inappropriate for Bitcoin Core to dictate
> policy on the network and we should honor user choice to turn off that fl=
ag
> if that=E2=80=99s what users want; if users are relying on v3=E2=80=99s p=
olicy restrictions
> for security then that is an unstable model and we should assume it will
> get broken[5].

Let's frame this question differently: given that there are potential
incentives around a hypothetical `-disable_v3_transaction_enforcement` flag,
why are we trying to prevent miners and others from experimenting with
incentives around `fullrbf`?

Yanking the `mempoolfullrbf` flag from Bitcoin Core v24.0 simply puts a
temporary roadblock in the face of full-rbf. Without that roadblock, we mig=
ht
find that some miners do in fact choose to enable it. The sooner we find th=
at
out, the sooner we can learn about the incentives involved in that decision.

Meanwhile, if we insted put up those roadblocks, we'll be designing mechani=
sms
like v3 blind, without the benefit of seeing how incentives play out fully.


This experimentation can't happen on testnet: incentives don't work properly
when there isn't money at stake. And the proposed reversion pull-reqs don't
even leave the option for testnet anyway. So we're left with one choice:
release a full-rbf option, and see what happens on mainnet.

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

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

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmNly9MACgkQLly11TVR
LzdMCBAAmb4e1yXu4C8Ysqpxu0MHkLySKMF85eqW00p9/8BVfqi4DRVwGVKZ0Yrt
ywKQZ2njke3Ln0ZWr7NNMQAcSCsFqcygX5cTImatD9oERtmwHOvIs3tZsioRrTnK
kkVEDJvctRUgiqhpg33c+2OG8VJF6WI6eqJ8CvDIauHHlB0CAW+Vr1VTelMMjZXP
J+amKe9V4pxnCH424j8wknD/qAZrj4F0PiC0cwUhvol/UiNWEKI4MEL8k2p+uXaY
sjBQWlMi2kWwW8D9M5BSh7JYYkZ4HeuQWgwMHuzo/zK3pQhO4ZynzLTGIekjjPbL
xQDzE/YSIz/iLvzXwgJkuN/1GT2r19aowdMmZ0awyFSZd+S81mRLxY+EL0h1pOCZ
clYLTyl6AAPTlrvgJc/lDOwFAWzLzSGYdPNnCMgr3HkyYI0v29aQDLiWwKwYQm3u
RV3Lad3EjYgXmvYUrNls8Xbifc4xClIqG4GJtELTVhdtt1pm2g0g0weLQw338RFY
4cbuI/hLaMJWcbGy2DMfjVNf49h4uqVGQfTc2tKXiSrp+jgWR3eaw41PDPJ/SoI6
2X/pV757U8ORI1QflX+bb0n83l/GS6ujhKitivuRfYN1iUw1nUdFyc045Gqz4W7h
/4sWK0cGaZVwHklrmkzFniA042VHioHMO0VgIHMxyL7mT7Z1jTs=
=kXGJ
-----END PGP SIGNATURE-----

--Gdsin4sPJgWt7i6w--