Michael Folkson [ARCHIVE] on Nostr: đź“… Original date posted:2022-08-04 đź“ť Original message:A short history of RBF and ...
đź“… Original date posted:2022-08-04
đź“ť Original message:A short history of RBF and BIP125
The history of BIP125 is as far as I’m 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’t ideal but mistakes happen and will continue to happen. I certainly do not intend any criticism whatsoever to any of the individuals involved. Thankfully this discrepancy doesn’t 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’t 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 have 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 the 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 (BIP) and a reference implementation (Bitcoin Core) I think the norm for material 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’t matter that 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. For consensus PRs this clearly doesn’t make sense. Many of us have and 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’t be the case) relying on them.
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’t 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 can 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 striving to do better and be more rigorous than whatever the standard was in 2015. But I don’t work on policy in Core full time and it is very possible that there are subtleties that I’m 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.html
[3]: https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220804/0036ee9e/attachment.html>;
đź“ť Original message:A short history of RBF and BIP125
The history of BIP125 is as far as I’m 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’t ideal but mistakes happen and will continue to happen. I certainly do not intend any criticism whatsoever to any of the individuals involved. Thankfully this discrepancy doesn’t 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’t 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 have 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 the 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 (BIP) and a reference implementation (Bitcoin Core) I think the norm for material 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’t matter that 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. For consensus PRs this clearly doesn’t make sense. Many of us have and 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’t be the case) relying on them.
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’t 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 can 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 striving to do better and be more rigorous than whatever the standard was in 2015. But I don’t work on policy in Core full time and it is very possible that there are subtleties that I’m 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.html
[3]: https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220804/0036ee9e/attachment.html>;