Michael Folkson [ARCHIVE] on Nostr: 📅 Original date posted:2022-08-04 📝 Original message:Thanks for this Luke. > ...

📅 Original date posted:2022-08-04
📝 Original message: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 at 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