diff options
| author | Peter Todd <pete@petertodd.org> | 2024-01-18 18:00:34 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2024-01-18 18:00:43 +0000 |
| commit | 5a8af12b1607a928c26878cd0f712f94bd99be5a (patch) | |
| tree | 380e08ff3f107a06857ddfda6827c57b9302c43b | |
| parent | 23048f377e9929a692a3f1fae834b3c715db245e (diff) | |
| download | pi-bitcoindev-5a8af12b1607a928c26878cd0f712f94bd99be5a.tar.gz pi-bitcoindev-5a8af12b1607a928c26878cd0f712f94bd99be5a.zip | |
Re: [bitcoin-dev] BIP process friction
| -rw-r--r-- | ed/9cfc2685cb1df4f95ca8a706fd2ac7ee269f42 | 227 |
1 files changed, 227 insertions, 0 deletions
diff --git a/ed/9cfc2685cb1df4f95ca8a706fd2ac7ee269f42 b/ed/9cfc2685cb1df4f95ca8a706fd2ac7ee269f42 new file mode 100644 index 000000000..3fa09569c --- /dev/null +++ b/ed/9cfc2685cb1df4f95ca8a706fd2ac7ee269f42 @@ -0,0 +1,227 @@ +Return-Path: <pete@petertodd.org> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 14118C0037 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 18 Jan 2024 18:00:43 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp3.osuosl.org (Postfix) with ESMTP id DCB626F5B9 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 18 Jan 2024 18:00:42 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org DCB626F5B9 +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=kPjAOzCt +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.602 +X-Spam-Level: +X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + RCVD_IN_DNSWL_LOW=-0.7, 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 0r5NBeF8KC3k + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 18 Jan 2024 18:00:41 +0000 (UTC) +Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com + [64.147.123.21]) + by smtp3.osuosl.org (Postfix) with ESMTPS id B84546F59A + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 18 Jan 2024 18:00:41 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org B84546F59A +Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) + by mailout.west.internal (Postfix) with ESMTP id 9A9333200B69; + Thu, 18 Jan 2024 13:00:40 -0500 (EST) +Received: from mailfrontend1 ([10.202.2.162]) + by compute4.internal (MEProxy); Thu, 18 Jan 2024 13:00:40 -0500 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= + messagingengine.com; h=cc:cc:content-type:content-type:date:date + :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to + :message-id:mime-version:references:reply-to:subject:subject:to + :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= + fm3; t=1705600840; x=1705687240; bh=GXcfjiYGUgSZ9/0wgERtT0vBBGIl + QIt62gttWn4T7VM=; b=kPjAOzCt7HJjsQg8LaZsbR/CAmhMitoShrh4KEAFBCtj + wFeeAO9k8ohdRdFmimoMTd4liBKHfiUR88J2ex7t3sibNQ0Qcq9VK7dBJdXhihZm + zauuCzxhCT/AA5BM6d/W70ybqkTe2fnnfOY2iT8Xq1iNFjVrfqMCjkeuVpc2kG0B + wWDDuxXwhO7Kysmwwzjd4BxDaR+W/ISAb8CX96UgQxwUaa6iuGwFrhnS3X51DLC7 + fTszHbnlJtvyeH3hasR+l+ihnyQyrXixNDzdJyexVQuAWsoTHjyAfB93z1aW8K4Y + AE4/OWd+Mz8QYHEdC2x5G2JoUxLMKmgYTK44UoKyZQ== +X-ME-Sender: <xms:R2epZbXgkzgBj4iBC58TzltPbOyVPkANiS3ku2v5jFm3e2chSLUxFQ> + <xme:R2epZTlnq1dj1dQYywD6mZosdjQrRzYgAu4FZag-HTZLM3bAXOrRXkuN3TvGJg-OA + n6uShSWrQa89atLDI8> +X-ME-Received: <xmr:R2epZXaBpOArVpyNmqgWxWMzQWrVxMslHbxqxG8bhr5b7-vib3Vd85wx4A_y> +X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdejkedgkedvucetufdoteggodetrfdotf + fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen + uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne + cujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtvdenucfhrhhomheprfgvthgv + rhcuvfhougguuceophgvthgvsehpvghtvghrthhouggurdhorhhgqeenucggtffrrghtth + gvrhhnpedttdegtdffteeukeffhfffkeekiefhteduvdetjeeujeffgeevgefhudetjefh + veenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhpvghtvghrthhouggurdhorhhgne + cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgv + sehpvghtvghrthhouggurdhorhhg +X-ME-Proxy: <xmx:R2epZWWPBmQ-4WOt9ppC8cCA0VVABJid56iXqkvBWQuJ_pxGdacoOw> + <xmx:R2epZVmQ_3630kaRFH5Tuo8MqrNYFqPzIuC_8-eKJFtVCr4NFaKoHg> + <xmx:R2epZTcIc29tJC1VeAIerRfrEccwdBQnP9VSt5SzuSICbtoeqUZMgQ> + <xmx:SGepZYvzculVrQXJCg8_XsH-KIM5si3CfhakTs6_y1pbXQP5DOwbiw> +Feedback-ID: i525146e8:Fastmail +Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, + 18 Jan 2024 13:00:39 -0500 (EST) +Received: by localhost (Postfix, from userid 1000) + id E3D385F849; Thu, 18 Jan 2024 18:00:34 +0000 (UTC) +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 +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: Thu, 18 Jan 2024 18:00:43 -0000 + + +--/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-- + |