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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
