From: Luke Dashjr <luke@dashjr•org>
To: bitcoin-dev@lists•linuxfoundation.org,
Michael Folkson <michaelfolkson@protonmail•com>
Subject: Re: [bitcoin-dev] RBF rules, setting policy defaults in Bitcoin Core and the role of BIPs
Date: Thu, 4 Aug 2022 19:35:13 +0000 [thread overview]
Message-ID: <202208041935.14223.luke@dashjr.org> (raw)
In-Reply-To: <zl3fWujFF4mSjfXz_d1gA73ALTnN_LaaGKyidRR6azX9toY2-j7cUkfVcU1ggIhJ0cjK9oA4q1jF5mDob6bdlDp4yaWHZKxxev-zjUQBqTk=@protonmail.com>
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
next prev parent reply other threads:[~2022-08-04 19:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-04 14:54 Michael Folkson
2022-08-04 18:06 ` Peter Todd
2022-08-04 19:35 ` Luke Dashjr [this message]
2022-08-04 21:47 ` Michael Folkson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202208041935.14223.luke@dashjr.org \
--to=luke@dashjr$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=michaelfolkson@protonmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox