diff options
author | Michael Folkson <michaelfolkson@protonmail.com> | 2024-01-19 19:27:30 +0000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2024-01-19 19:27:48 +0000 |
commit | 61a350e161c7b4b8ae5585c8d3a41ce51c4d00d1 (patch) | |
tree | 85cc1640879d5d6257051e57a6e59c66c5f93821 | |
parent | db7a711b6fdb661cf8de45ce31dfa166440d04ab (diff) | |
download | pi-bitcoindev-61a350e161c7b4b8ae5585c8d3a41ce51c4d00d1.tar.gz pi-bitcoindev-61a350e161c7b4b8ae5585c8d3a41ce51c4d00d1.zip |
Re: [bitcoin-dev] BIP process friction
-rw-r--r-- | fe/627612db7916b76d0678b8125b3726d724210d | 250 |
1 files changed, 250 insertions, 0 deletions
diff --git a/fe/627612db7916b76d0678b8125b3726d724210d b/fe/627612db7916b76d0678b8125b3726d724210d new file mode 100644 index 000000000..e02258427 --- /dev/null +++ b/fe/627612db7916b76d0678b8125b3726d724210d @@ -0,0 +1,250 @@ +Return-Path: <michaelfolkson@protonmail.com> +Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 9BE3BC0037 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 19 Jan 2024 19:27:48 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp1.osuosl.org (Postfix) with ESMTP id 6481F84691 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 19 Jan 2024 19:27:48 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 6481F84691 +Authentication-Results: smtp1.osuosl.org; + dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com + header.a=rsa-sha256 header.s=protonmail3 header.b=JaObX/HQ +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.099 +X-Spam-Level: +X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, + SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no +Received: from smtp1.osuosl.org ([127.0.0.1]) + by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id nfO7yNsd5-WC + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 19 Jan 2024 19:27:47 +0000 (UTC) +Received: from mail-0201.mail-europe.com (mail-0201.mail-europe.com + [51.77.79.158]) + by smtp1.osuosl.org (Postfix) with ESMTPS id B2EFD84690 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 19 Jan 2024 19:27:46 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org B2EFD84690 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; + s=protonmail3; t=1705692457; x=1705951657; + bh=VEjd0Kxu3v+OJIzzm1L5r/pYxwhPYQ3qPujPusiIi5E=; + h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: + Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: + Message-ID:BIMI-Selector; + b=JaObX/HQeRTkMPbc7yVOvKccWW9+vYzIK5FRNTTNFkt2nztjaxHKZD240Hm4B90Bz + pQkd/1kftY/ycXxG3WfJgYCTj5jWuoTR1Xyl9GbWwa0NACyTn3zzDYFfG0y7mF/EYo + XYdzWGu6n0G5EzaE6Aw91x/T8lJknVK/RwWABjtwpN7rr95c31cbYufectpzq3Qwdv + chRyrcUJgDlqzqM2Gwrd+i0gsCPXSBMRyDtQLyZiQLqcciOSAI9pQcz9QabG+RodQD + hSngIMYgMhzN6FOPpNLjnrq7ePyH3hKYPvX0vy2pjr3cHJfIJF7AYirZuEDm70p0wW + 0wMFO8MuenMSA== +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 +X-Mailman-Approved-At: Tue, 23 Jan 2024 13:46:37 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] BIP process friction +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: Fri, 19 Jan 2024 19:27:48 -0000 + +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 + |