Date: Fri, 19 Jan 2024 19:27:30 +0000
To: Peter Todd <pete@petertodd.org>
From: Michael Folkson <michaelfolkson@protonmail.com>
Message-ID: <WBjioXYlG8LU31KNQAn_r2g7kDGuH4OPUzOhpUqvCM1W43sz70L2KcvHjmFzeBihDTRkXvDGUswJCAZlWitw5ChJYOj3CxW9f-cMmCX33cg=@protonmail.com>
In-Reply-To: <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>
 <ZalnQqvbxhxm8UG2@petertodd.org>
Feedback-ID: 27732268:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP process friction
Precedence: list

Thanks for this Peter, really helpful.=20

> 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 wallet=
s
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.

Yes I'd personally lean towards this view too. Certainly when you go into a=
lternative asset territory (e.g. Counterparty, Liquid (Network) assets, Tap=
root assets) it is moving away from what you can do with the Bitcoin asset/=
currency and into building a new ecosystem with a different asset/currency.=
 I would agree that that should probably be out of scope for *Bitcoin* Impr=
ovement Proposals without having any particular opinion on the utility of a=
ny of those ecosystems.

> just the other day I ran into someone
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.

I suspected this might be the case but to actually have a data point to bac=
k that up (beyond I personally find it unnecessarily confusing and hard to =
follow) is helpful, thanks.

> Finally, I think the lesson to be learned here is that mempool policy is =
better
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 i=
s
actually implemented, and more importantly, *why* it is implemented and wha=
t
trade-offs were made to get there. It's quite possible that this "living
documentation" requirement rules out the BIP process.

I get the "living", evolving point. Policy proposals are definitely differe=
nt to say consensus proposals where assuming they are ever activated you'd =
expect them to stay static for the rest of Bitcoin's existence barring mino=
r cleanups, clarifications etc. However, one possible addition in a new BIP=
 3 process would be the introduction of versioning for a particular BIP e.g=
. BIP 789 version 2 which would be more conducive to these evolving proposa=
ls such as policy proposals. You could then update a BIP without needing a =
new BIP number for every material update.

I'll wait to hear what Luke thinks on this. Beyond the friction concern I t=
hink improving the BIP process for consensus and policy proposals would be =
the biggest potential win for a BIP 3 update.

Thanks also to Kalle too for his 18 month stint as a BIP editor :)

--
Michael Folkson
Email: michaelfolkson at protonmail.com
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F


Learn about Bitcoin: https://www.youtube.com/@portofbitcoin


On Thursday, 18 January 2024 at 18:00, Peter Todd <pete@petertodd.org> wrot=
e:


> On Wed, Jan 17, 2024 at 05:29:48PM +0000, Michael Folkson via bitcoin-dev=
 wrote:
>=20
> > Hey Luke
> >=20
> > I'd be happy to pick up working on BIP 3 again ([0], [1]) in light of t=
his issue and others that are repeatedly cropping up (e.g. confusion on the=
 recommended flow for working on proposed consensus changes, when to open a=
 pull request to bitcoin-inquisition, when to open a pull request to Core, =
when to include/exclude activation params etc).
> >=20
> > I don't think there is much I personally disagree with you on with rega=
rds to BIPs but one issue where I do think there is disagreement is on whet=
her 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 multipart=
y protocols (e.g. vaults) there are and will continue to be draft proposals=
 on changing the default policy rules in Bitcoin Core and/or alternative im=
plementations. As these proposals are for default policy rules and not cons=
ensus rules there is absolutely no obligation for Bitcoin Core and/or alter=
native implementations to change their default policy rules nor users to ru=
n any particular policy rules (default or otherwise). The authors of these =
draft proposals are clearly recommending what they think the default policy=
 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 complexitie=
s involved in designing default policy rules so any recommendation(s) to si=
gnificantly upgrade default policy rules would benefit from being subject t=
o a spec process. This would also aid the review of any policy related pull=
 requests in Bitcoin Core and/or alternative implementations. An interestin=
g recent case study washttps://github.com/bitcoin/bitcoin/pull/22665and Bit=
coin Core not implementing the exact wording of BIP 125 RBF. In this case (=
for various reasons) as a response Bitcoin Core just removed references to =
BIP 125 and started documenting the replacement to BIP 125 rules in the Bit=
coin Core repo instead. However, it is my view that recommendations for def=
ault policy rules should be recommendations to all implementations, reviewe=
d by Lightning and multiparty protocol developers (not just Bitcoin Core) a=
nd hence they would benefit from being standardized and being subject to a =
specification process. I will reiterate once again though that policy rules=
 are not consensus rules. Consensus rules are much closer to an obligation =
as divergences from consensus rules risk the user being forked off the bloc=
kchain and could ultimately end up in network splits. This does not apply t=
o policy rules."
> >=20
> > Are you open to adjusting your stance on proposed policy changes being =
BIPed? I do think it really stunts work on proposed default policy changes =
and people's ability to follow work on these proposals when the specificati=
ons for them are littered all over the place. I've certainly struggled to f=
ollow the latest state of V3 policy proposals without clear reference point=
s for the latest state of these proposals e.g. [3]. In addition some propos=
ed 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 ju=
st refer to a separate policy BIP rather than including proposals for both =
policy and consensus in the same BIP.
>=20
>=20
> BIP-125 is I think an interesting case study. It is a much more fundament=
al
> standard than Ordinals or Taproot Assets, in the sense that transaction
> replacement is expected to be used by essentially all wallets as all wall=
ets
> 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.
>=20
> The V3 proposal, and ephemeral anchors, would be expected to be used by a=
 wide
> 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 s=
omeone
> that didn't know RBF Rule #6 existed, which Core added on top of BIP-125,=
 and
> had made a mistake in their safety analysis of a protocol due to that.
>=20
> Meanwhile, engineering documentation on V3 is extremely lacking, with bas=
ics
> like worked through use-case examples not being available. We don't even =
have
> solid agreement let alone documentation on how Lightning channels are mea=
nt to
> use V3 transactions and what the trade-offs are. And that has lead to mis=
taken
> claims, such as overstating(1) the benefit V3 transactions in their curre=
nt
> form have for transaction pinning.
>=20
> I don't think V3 necessarily needs a formal BIP. But it would benefit fro=
m a
> proper engineering process where use-cases are actually worked out and an=
alyzed
> properly.
>=20
> Finally, I think the lesson to be learned here is that mempool policy is =
better
> 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 wha=
t
> trade-offs were made to get there. It's quite possible that this "living
> documentation" requirement rules out the BIP process.
>=20
> 1) https://petertodd.org/2023/v3-txs-pinning-vulnerability
>=20
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org