path: root/47/98e41d7ff8e9f316e6d0eedd8200b6e6130772

Return-Path: <pete@petertodd.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 3E602C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  5 Nov 2022 02:35:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 049FB60ABB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  5 Nov 2022 02:35:15 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 049FB60ABB
Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key,
 unprotected) header.d=messagingengine.com header.i=@messagingengine.com
 header.a=rsa-sha256 header.s=fm3 header.b=ecK3cd4d
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.603
X-Spam-Level: 
X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id R3jasFEoLETP
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  5 Nov 2022 02:35:13 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 2E5AD60AB7
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com
 [64.147.123.24])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 2E5AD60AB7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  5 Nov 2022 02:35:13 +0000 (UTC)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43])
 by mailout.west.internal (Postfix) with ESMTP id 440383200914;
 Fri,  4 Nov 2022 22:35:09 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
 by compute3.internal (MEProxy); Fri, 04 Nov 2022 22:35:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-type:date:date:feedback-id
 :feedback-id:from:from:in-reply-to:in-reply-to:message-id
 :mime-version:references:reply-to:sender:subject:subject:to:to
 :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=
 fm3; t=1667615708; x=1667702108; bh=OoWsbe5fsLFd50WHamsRilsHQWrI
 +BFhkIAOIXpL3ag=; b=ecK3cd4dEPQn02lgtJfT40+xgWb94gEUc2Hb+vE7i1tK
 K2Ng1y6huMMv4zk6gImecZvdyUhk89m/JyQ/QRDKzLSNCnC7ZaMS2oke6c+ZrqbJ
 Nm70Ka4i9o5XRqoYk+0Oyn7KpfAQbhTsIK1PLATQq+OwlKr0uOTN2+4luaOIpC18
 WFJ3jJzaSRp4rPttLxvjiIiVkwkbF5JCW4X3o0oF8/tINQD60rei2FOsQKyBdzIQ
 UGtokLcFbUcXAEcrtqlOJCmP6oZBGgICpEAF19SyCdHR8LcRuBjyA6wsvrAt85UF
 IlyF2ibJXmLpmqJKQ7pMkhq1uTAWM56cEXYHdMDFxA==
X-ME-Sender: <xms:3MtlY0I5FmXXJxrOD7lwoApzgesFzysn97qBony2P17WmIYNxKzveg>
 <xme:3MtlY0LJtU4PEUvhQheB1StrU2xMxmpv8Yi9XkGIvo9xUKdwzSUpxGfNZfM9b0B5a
 VyJA3f-A_mWaL0pn9w>
X-ME-Received: <xmr:3MtlY0tVcJLjK0k30YMwoymOBAz8sw1w6_GX5_8AGFj-Mg9-tEQNvaVuXzEcLQs5gzTPTNSA6CqOrNYXk1xepXHg4OzxYSyPTC5BgJFMOA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrvddvgdegjecutefuodetggdotefrodftvf
 curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
 uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
 fjughrpeffhffvuffkfhggtggujgesghdtreertddtjeenucfhrhhomheprfgvthgvrhcu
 vfhougguuceophgvthgvsehpvghtvghrthhouggurdhorhhgqeenucggtffrrghtthgvrh
 hnpeejkeeuheekffetfefftdegjeekteeiveehieeugefgueekgeevueevhefghedtkeen
 ucffohhmrghinhepphgvthgvrhhtohguugdrohhrghenucevlhhushhtvghrufhiiigvpe
 dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvghtvgesphgvthgvrhhtohguugdrohhr
 gh
X-ME-Proxy: <xmx:3MtlYxYffTarrFsLikUpTd19krpcosg65kUaPuXpyPCSYDAyW6Ko8Q>
 <xmx:3MtlY7bEv5W5DEFG1MIiA_LQRTJPhYbHG46oWbO9WKr-PoFOF1ZRrQ>
 <xmx:3MtlY9DhELoC4urdf6Htkprwb-WWdODCjV9XkpKwqaGAEH2nMVUAxg>
 <xmx:3MtlY3GxJTF8RW5BnHmbbBc1uY82qR_mwOOW2naIh0IYRr5B115WXw>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 4 Nov 2022 22:35:07 -0400 (EDT)
Received: by localhost (Postfix, from userid 1000)
 id D52EA5F82F; Fri,  4 Nov 2022 22:35:03 -0400 (EDT)
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Nov 2022 02:35:15 -0000


--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--