summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMichael Folkson <michaelfolkson@protonmail.com>2024-01-19 19:27:30 +0000
committerbitcoindev <bitcoindev@gnusha.org>2024-01-19 19:27:48 +0000
commit61a350e161c7b4b8ae5585c8d3a41ce51c4d00d1 (patch)
tree85cc1640879d5d6257051e57a6e59c66c5f93821
parentdb7a711b6fdb661cf8de45ce31dfa166440d04ab (diff)
downloadpi-bitcoindev-61a350e161c7b4b8ae5585c8d3a41ce51c4d00d1.tar.gz
pi-bitcoindev-61a350e161c7b4b8ae5585c8d3a41ce51c4d00d1.zip
Re: [bitcoin-dev] BIP process friction
-rw-r--r--fe/627612db7916b76d0678b8125b3726d724210d250
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
+