Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9F4FCC002D for ; Thu, 4 Aug 2022 19:36:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 56AB8831AC for ; Thu, 4 Aug 2022 19:36:47 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 56AB8831AC Authentication-Results: smtp1.osuosl.org; dkim=pass (1024-bit key) header.d=dashjr.org header.i=@dashjr.org header.a=rsa-sha256 header.s=zinan header.b=mScY1/31 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.401 X-Spam-Level: X-Spam-Status: No, score=-4.401 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 8m4qswJUDHL0 for ; Thu, 4 Aug 2022 19:36:45 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 2448A831A7 Received: from zinan.dashjr.org (zinan.dashjr.org [IPv6:2001:470:88ff:2f::1]) by smtp1.osuosl.org (Postfix) with ESMTP id 2448A831A7 for ; Thu, 4 Aug 2022 19:36:44 +0000 (UTC) Received: from ishibashi.lan (unknown [12.151.133.18]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 6836238AD736; Thu, 4 Aug 2022 19:35:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan; t=1659641803; bh=0qAqWED/VlkdT20SaK35dphzwz6YIySoOarjFe447Vo=; h=From:To:Subject:Date:References:In-Reply-To; b=mScY1/31n4+9EAvXrJ+0hN7ZB+11AgqIMSY5dXsNWAkkTqh50nh3RW38QsRVRiW/s bxex/DgoJkBuIdGRo6cCDbPgwpeWmfEvTrtAM1HrNZSkLoIizd7VMCuwLQ4yxJITbr ec8QUL1T2VasdT/UYPfchjAVYY5+cxvM2lqYpis0= X-Hashcash: 1:25:220804:bitcoin-dev@lists.linuxfoundation.org::Em9sqdzo/MOXbakr:1mc9 X-Hashcash: 1:25:220804:michaelfolkson@protonmail.com::gKXW1xS4QgLAaoFi:jQ1zb From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, Michael Folkson Date: Thu, 4 Aug 2022 19:35:13 +0000 User-Agent: KMail/1.9.10 References: In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <202208041935.14223.luke@dashjr.org> Subject: Re: [bitcoin-dev] RBF rules, setting policy defaults in Bitcoin Core and the role of BIPs X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2022 19:36:47 -0000 Policy is a subjective per-node, not systemic, not enforcable or expectable= ,=20 and generally not eligible for standardization. The reason BIP125 is an exception, is because it is more than just policy. It is a way for wallets and nodes to communicate. The wallet is saying "thi= s=20 is the policy I would like you to apply to potential replacements of these= =20 transactions". Whether the nodes abide this request or not, the purpose and= =20 justification of the BIP is to standardize the communication of it. Since BIP125 is widely implemented, it should not be changed except for=20 corrections to things which are errors deviating from the original intent. If there is merely a new policy intended to be conveyed, a new BIP should b= e=20 written that is distinguishable from BIP125 (perhaps drop the sequence numb= er=20 by 1 more). However, unless nodes are going to honour both the BIP125-reque= st=20 policy *and* a new policy, it might be simpler for them to just not honour= =20 the requested BIP125 policy exactly. Also note that security should NEVER depend on assumptions of node policies= =2E=20 Doing so would be a serious security vulnerability, regardless of what actu= al=20 network policies are. It's fine to blame nodes/miners if they single out yo= ur=20 transactions, but if it's just a matter of a general policy your transactio= ns=20 are failing to meet, that's on the sender/L2 to adapt. Luke On Thursday 04 August 2022 14:54:54 Michael Folkson via bitcoin-dev wrote: > A short history of RBF and BIP125 > > The history of BIP125 is as far as I=E2=80=99m aware this. RBF rules were= merged > into Bitcoin Core in November 2015 [0]. Following that merge David Harding > and Peter Todd drafted a BIP (BIP125 [1]) outlining the RBF rules that had > been implemented in Bitcoin Core. The rationales for the rules in the BIP > was a bit lacking (in my opinion) but recall this is 2015 (7 years ago!) > when L2 protocols were in their infancy. Certainly the research on the > security of L2 protocols has come a long way since and we have a much > better idea of some of the possible attacks on L2 protocols that to some > extent are impacted by policy rules. > > In addition it was discovered [2] in May 2021 that the Bitcoin Core > implementation of the RBF rules had never matched the RBF rules outlined = in > BIP125. Clearly this isn=E2=80=99t ideal but mistakes happen and will con= tinue to > happen. I certainly do not intend any criticism whatsoever to any of the > individuals involved. Thankfully this discrepancy doesn=E2=80=99t seem to= have > resulted in any loss of funds or disruption. However, cross checking a > specification with an implementation presumably led to the discovery and > allowed for a post mortem on why the implementation didn=E2=80=99t match = the > specification. > > There seems to be two views on what to do next given that the RBF rules > need to be updated. One is to ditch the idea of a specification for RBF > rules and just document them in the Core repo instead. The other is to ha= ve > a new specification for the RBF rules in Core and attempt to correct the > mistakes made with BIP125 by having a BIP that does correctly outline the > RBF rules implemented in Core and includes detailed rationales for why > those RBF rules have been implemented. > > Should anyone care about where things are documented? > > Perhaps not but I think if you are a stakeholder in L2 protocol security > you should. Suppose in the long term future an attacker exploits a L2 > vulnerability that is based on the default policy set by the dominant > implementation on the network (Bitcoin Core). Which would you prefer the > norm to be? A detailed static, well reviewed BIP standard that lays out t= he > updated RBF rules and the rationales for those new rules that is reviewed > outside the Core repo and hence not just by Core reviewers? Or cross > checking Bitcoin Core code with non-standardized Core documentation > typically reviewed only by Core reviewers? > > For the same reason the norm for consensus changes is a specification (BI= P) > and a reference implementation (Bitcoin Core) I think the norm for materi= al > step change policy changes should be a specification (BIP) and a reference > implementation (Bitcoin Core). Policy is of course less risky than > consensus for various reasons including there being no chain split risk if > the user changes the default policy of their node. Alternative > implementations are free to set entirely different policy rules too. But > with L2 protocol security to some extent relying on policy whether we like > it or not I think we should aspire to similar standards where possible for > policy too. > > Specifications and implementations > > The Bitcoin Core review process generally requires Concept ACKs, Approach > ACKs and then code review, testing ACKs in that order. The reason for this > is even if the code is perfect if it is implementing a concept or an > approach that informed reviewers oppose then it doesn=E2=80=99t matter th= at the > code is perfect. Documentation is generally done post merge if at all. For > most PRs e.g. refactors this makes sense. There is no point documenting > something in advance if it is still under review or may not get merged. F= or > consensus PRs this clearly doesn=E2=80=99t make sense. Many of us have an= d continue > to cross check the Taproot BIPs with the Taproot reference implementation > in Bitcoin Core. Having two points of reference released simultaneously is > treating consensus changes with the highest possible standards we can. I > think we should strive towards the highest possible standards for step > change default policy changes in Core too given L2 protocol security is > (unfortunately, ideally this wouldn=E2=80=99t be the case) relying on the= m. > > What are the new RBF rules replacing the BIP125 rules? > > The new RBF rules as implemented in Core today are documented here [3] in > the Core repo (thanks for the link glozow). To the extent that these are a > work in progress or close to final (i.e. intended to be static) I don=E2= =80=99t > know. The devs who work on policy will have a much better idea on these > questions than me. Will the new RBF rules continue to be iterated upon as > new research on L2 security comes to light? Will this iteration make it > impossible to maintain a static set of rules that the broader ecosystem c= an > get comfortable with? Or is a new static set of RBF rules close to being > finalized and there is just an aversion to using BIPs and a specification? > > Generally, as time passes, the ecosystem grows, layers on top of the base > layer get built out I get uncomfortable with what I perceive (correctly or > incorrectly) as a slip in standards. If anything it should be going in the > opposite direction. Standards should be improving and we should be strivi= ng > to do better and be more rigorous than whatever the standard was in 2015. > But I don=E2=80=99t work on policy in Core full time and it is very possi= ble that > there are subtleties that I=E2=80=99m entirely missing here. I think this= is the > right forum to ask about those subtleties though. Thanks to those who work > on this important area. > > [0]: https://github.com/bitcoin/bitcoin/pull/6871 > > [1]: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki > > [2]: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018893.h= tm >l > > [3]: > https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replace= me >nts.md > > -- > Michael Folkson > Email: michaelfolkson at [protonmail.com](http://protonmail.com/) > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3