* [bitcoin-dev] RBF rules, setting policy defaults in Bitcoin Core and the role of BIPs
@ 2022-08-04 14:54 Michael Folkson
2022-08-04 18:06 ` Peter Todd
2022-08-04 19:35 ` Luke Dashjr
0 siblings, 2 replies; 4+ messages in thread
From: Michael Folkson @ 2022-08-04 14:54 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 5940 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 9561 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] RBF rules, setting policy defaults in Bitcoin Core and the role of BIPs
2022-08-04 14:54 [bitcoin-dev] RBF rules, setting policy defaults in Bitcoin Core and the role of BIPs Michael Folkson
@ 2022-08-04 18:06 ` Peter Todd
2022-08-04 19:35 ` Luke Dashjr
1 sibling, 0 replies; 4+ messages in thread
From: Peter Todd @ 2022-08-04 18:06 UTC (permalink / raw)
To: Michael Folkson, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2767 bytes --]
On Thu, Aug 04, 2022 at 02:54:54PM +0000, Michael Folkson via bitcoin-dev wrote:
> 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?
They really shouldn't.
The nature of L2 punishment protocols is that transaction relay schemes are
additive security: every different way that a punishment tx could get broadcast
and mined is a different way that the punishment scheme could succeed. We
should be thinking about how to add diversity and robustness to this in the
form of different schemes, rather than trying to specify exactly how we expect
these txs to be broadcast. In particular, you have to accept that different
schemes will exist, and an adversary could use those schems.
For the near-term, an important part of this is to get package relay and
package replacements implemented, to avoid edge-cases in multiple-tx schemes.
It'd also be good to specify something entirely different, like a hashcase
based broadcast scheme.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] RBF rules, setting policy defaults in Bitcoin Core and the role of BIPs
2022-08-04 14:54 [bitcoin-dev] RBF rules, setting policy defaults in Bitcoin Core and the role of BIPs Michael Folkson
2022-08-04 18:06 ` Peter Todd
@ 2022-08-04 19:35 ` Luke Dashjr
2022-08-04 21:47 ` Michael Folkson
1 sibling, 1 reply; 4+ messages in thread
From: Luke Dashjr @ 2022-08-04 19:35 UTC (permalink / raw)
To: bitcoin-dev, Michael Folkson
Policy is a subjective per-node, not systemic, not enforcable or expectable,
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 "this
is the policy I would like you to apply to potential replacements of these
transactions". Whether the nodes abide this request or not, the purpose and
justification of the BIP is to standardize the communication of it.
Since BIP125 is widely implemented, it should not be changed except for
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 be
written that is distinguishable from BIP125 (perhaps drop the sequence number
by 1 more). However, unless nodes are going to honour both the BIP125-request
policy *and* a new policy, it might be simpler for them to just not honour
the requested BIP125 policy exactly.
Also note that security should NEVER depend on assumptions of node policies.
Doing so would be a serious security vulnerability, regardless of what actual
network policies are. It's fine to blame nodes/miners if they single out your
transactions, but if it's just a matter of a general policy your transactions
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’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.htm
>l
>
> [3]:
> https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replaceme
>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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] RBF rules, setting policy defaults in Bitcoin Core and the role of BIPs
2022-08-04 19:35 ` Luke Dashjr
@ 2022-08-04 21:47 ` Michael Folkson
0 siblings, 0 replies; 4+ messages in thread
From: Michael Folkson @ 2022-08-04 21:47 UTC (permalink / raw)
To: Luke Dashjr; +Cc: bitcoin-dev
Thanks for this Luke.
> Since BIP125 is widely implemented, it should not be changed except for corrections to things which are errors deviating from the original intent.
In this example the BIP125/RBF rules implemented in Core are (and always have been) different to the rules as described in BIP125. As far as I know other implementations have also followed how it is implemented in Core rather than as described in BIP125. So we have the BIP125 rules, BIP125/RBF as implemented in Core and future intended changes to how RBF rules are implemented in Core which may or may not also be in a state of flux. I take the view that once those new RBF rules are "finalized" there should be a new BIP but others disagree.
> Also note that security should NEVER depend on assumptions of node policies. Doing so would be a serious security vulnerability, regardless of what actual network policies are.
You regularly state this and of course you're right. I tried to allude that it is far from ideal that L2 security is impacted by default policy rules to any extent in my post. But if it is a matter of fact that default policy rules impact the viability of some L2 protocol attacks today what should one do when setting default policy rules in the dominant implementation on the network? I think you lean towards not factoring that in whatsoever to decisions on default policy rules whereas (perhaps mistakenly) I lean towards factoring that in to default policy rule decisions especially when there don't seem to be many other factors to consider. In the case of Lightning Network I think we both want it to succeed and hopefully in the long term default policy rules will have no impact on its security whatsoever. But today that seems to not be the case.
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Thursday, August 4th, 2022 at 20:35, Luke Dashjr <luke@dashjr•org> wrote:
> Policy is a subjective per-node, not systemic, not enforcable or expectable,
> 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 "this
> is the policy I would like you to apply to potential replacements of these
> transactions". Whether the nodes abide this request or not, the purpose and
> justification of the BIP is to standardize the communication of it.
>
> Since BIP125 is widely implemented, it should not be changed except for
> 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 be
> written that is distinguishable from BIP125 (perhaps drop the sequence number
> by 1 more). However, unless nodes are going to honour both the BIP125-request
> policy and a new policy, it might be simpler for them to just not honour
> the requested BIP125 policy exactly.
>
> Also note that security should NEVER depend on assumptions of node policies.
> Doing so would be a serious security vulnerability, regardless of what actual
> network policies are. It's fine to blame nodes/miners if they single out your
> transactions, but if it's just a matter of a general policy your transactions
> 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’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.
> >
> > l
> >
> > nts.md
> >
> > --
> > Michael Folkson
> > Email: michaelfolkson at protonmail.com
> > Keybase: michaelfolkson
> > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-08-06 15:48 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-04 14:54 [bitcoin-dev] RBF rules, setting policy defaults in Bitcoin Core and the role of BIPs Michael Folkson
2022-08-04 18:06 ` Peter Todd
2022-08-04 19:35 ` Luke Dashjr
2022-08-04 21:47 ` Michael Folkson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox