Feedback-ID: i525146e8:Fastmail
Date: Thu, 18 Jan 2024 18:00:34 +0000
From: Peter Todd <pete@petertodd.org>
To: Michael Folkson <michaelfolkson@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <ZalnQqvbxhxm8UG2@petertodd.org>
References: <Zac+rMC/c+qTmSxY@erisian.com.au>
 <CACrqygDJRtZN4Oo30=DaFO2KYkn1H+Daxh5cinHKz66Uvn9BVg@mail.gmail.com>
 <030e09b8-3831-45ff-92ad-9531ae277f80@dashjr.org>
 <6ZZYFympMLvwZ3otE_ebPh3wAuPFYb1BKL_3O_NrlQYKfsAJNlobGrZQjK23BxNeIdJ_8x_SAhgF_po1qO68MI_XONG7aPsnEL45y8SNndQ=@protonmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="/cJ9MfxEAUIuSSPr"
Content-Disposition: inline
In-Reply-To: <6ZZYFympMLvwZ3otE_ebPh3wAuPFYb1BKL_3O_NrlQYKfsAJNlobGrZQjK23BxNeIdJ_8x_SAhgF_po1qO68MI_XONG7aPsnEL45y8SNndQ=@protonmail.com>
Subject: Re: [bitcoin-dev] BIP process friction
Precedence: list


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

On Wed, Jan 17, 2024 at 05:29:48PM +0000, Michael Folkson via bitcoin-dev w=
rote:
> Hey Luke
>=20
> I'd be happy to pick up working on BIP 3 again ([0], [1]) in light of thi=
s issue and others that are repeatedly cropping up (e.g. confusion on the r=
ecommended flow for working on proposed consensus changes, when to open a p=
ull request to bitcoin-inquisition, when to open a pull request to Core, wh=
en to include/exclude activation params etc).
>=20
> I don't think there is much I personally disagree with you on with regard=
s to BIPs but one issue where I do think there is disagreement is on whethe=
r proposed default policy changes can/should be BIPed.
>=20
> I previously drafted this on proposed default policy changes [2]:
>=20
> "To address problems such as pinning attacks on Lightning and multiparty =
protocols (e.g. vaults) there are and will continue to be draft proposals o=
n changing the default policy rules in Bitcoin Core and/or alternative impl=
ementations. As these proposals are for default policy rules and **not** co=
nsensus rules there is absolutely no obligation for Bitcoin Core and/or alt=
ernative implementations to change their default policy rules nor users to =
run any particular policy rules (default or otherwise). The authors of thes=
e draft proposals are clearly recommending what they think the default poli=
cy rules should be and what policy rules users should run but it is merely =
a recommendation. There are a lot of moving parts, subtleties and complexit=
ies involved in designing default policy rules so any recommendation(s) to =
significantly upgrade default policy rules would benefit from being subject=
 to a spec process. This would also aid the review of any policy related pu=
ll requests in Bitcoin Core and/or alternative implementations. An interest=
ing recent case study washttps://github.com/bitcoin/bitcoin/pull/22665and B=
itcoin Core not implementing the exact wording of BIP 125 RBF. In this case=
 (for various reasons) as a response Bitcoin Core just removed references t=
o BIP 125 and started documenting the replacement to BIP 125 rules in the B=
itcoin Core repo instead. However, it is my view that recommendations for d=
efault policy rules should be recommendations to all implementations, revie=
wed by Lightning and multiparty protocol developers (not just Bitcoin Core)=
 and hence they would benefit from being standardized and being subject to =
a specification process. I will reiterate once again though that policy rul=
es are **not** consensus rules. Consensus rules are much closer to an oblig=
ation as divergences from consensus rules risk the user being forked off th=
e blockchain and could ultimately end up in network splits. This does not a=
pply to policy rules."
>=20
> Are you open to adjusting your stance on proposed policy changes being BI=
Ped? I do think it really stunts work on proposed default policy changes an=
d people's ability to follow work on these proposals when the specification=
s for them are littered all over the place. I've certainly struggled to fol=
low the latest state of V3 policy proposals without clear reference points =
for the latest state of these proposals e.g. [3]. In addition some proposed=
 consensus change BIPs are starting to want to include sections on policy (=
e.g. BIP345, OP_VAULT [4]) where it would be much better if they could just=
 refer to a separate policy BIP rather than including proposals for both po=
licy and consensus in the same BIP.

BIP-125 is I think an interesting case study. It is a much more fundamental
standard than Ordinals or Taproot Assets, in the sense that transaction
replacement is expected to be used by essentially all wallets as all wallets
have to deal with fee-rate fluctuations; I do not think that Ordinals or
Taproot assets are appropriate BIP material due to their niche use-case.

The V3 proposal, and ephemeral anchors, would be expected to be used by a w=
ide
range of contracting protocols, most notably lightning. This isn't quite as
broad usage as BIP-124 RBF. But it is close. And yes, Core making changes to
what is essentially BIP125 has an impact: just the other day I ran into som=
eone
that didn't know RBF Rule #6 existed, which Core added on top of BIP-125, a=
nd
had made a mistake in their safety analysis of a protocol due to that.

Meanwhile, engineering documentation on V3 is extremely lacking, with basics
like worked through use-case examples not being available. We don't even ha=
ve
solid agreement let alone documentation on how Lightning channels are meant=
 to
use V3 transactions and what the trade-offs are. And that has lead to mista=
ken
claims, such as overstating(1) the benefit V3 transactions in their current
form have for transaction pinning.

I don't think V3 necessarily needs a formal BIP. But it would benefit from a
proper engineering process where use-cases are actually worked out and anal=
yzed
properly.

Finally, I think the lesson to be learned here is that mempool policy is be=
tter
served by *living* documentation that gets updated to reflect the real worl=
d.
There's no easy way for someone to get up to speed on what mempool policy is
actually implemented, and more importantly, *why* it is implemented and what
trade-offs were made to get there. It's quite possible that this "living
documentation" requirement rules out the BIP process.

1) https://petertodd.org/2023/v3-txs-pinning-vulnerability

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

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

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmWpZ0AACgkQLly11TVR
LzcqSQ//T6XoLGY9iP7ZqUZhU0fc6mKHgzVxCowJP/3LPJr5g4JMfMU2WkU4QNI2
niGbXgSRc/Rm4FnDmOSgzxJ4uLyYQ9NbieDf3z+ljH53geRxhPLZjKsgSj/1sIpR
euqXOh4aRtTz5edqn2LGgzA0G+7FXO4jOyqCmpjkpLFqGkMVp8e5M9Sb+/Zx70IT
e7hyXEK0sGU4Qmyf/OBD9M/FlzFq4MNRH9CbVf1WvdTolWy32GdZhymNvfObm/Wd
hSO6NouD05ggyeeDGVonhoMMtnqUW7eBHKSQRCgN57Qyor8Nen9yhCv4W1lbhQIe
Rx5DYZFZTkF3X2I0CILOeI+8B6+jFrbUVRnCMW6RZOBrR4sY6RUy2IHu9yX4KHZh
CkR+dip8olLNCNXDyxYSpD31pugyQMoeXycyEt1lWuZ6LM3kY6Q/aQovC28oD49Q
PlniZfm4mUPcV8O7ZsqPCDvISH6NQeUCb+gzoHbCaJgd3jA1x7yRlwEhS1OIiFxp
HCdOguYaobaaF+X5l8sGHtT5pGccV0R/+/KJ0EHvAKojeLFlWJVeYWyaRRIHABZ6
sKKpgRy1kqpqB2cUMPD7XCdOZmZFvXG639qFjg9/zbQo08po2yoaJX+2YgxqvG3H
6BrcvnZIbPjmAX1CnHE/fye26Vrnnve+JNyqjQikuYuQCSLN+Yw=
=k1F7
-----END PGP SIGNATURE-----

--/cJ9MfxEAUIuSSPr--