From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
 Michael Folkson <michaelfolkson@protonmail.com>
Date: Thu, 4 Aug 2022 19:35:13 +0000
User-Agent: KMail/1.9.10
References: <zl3fWujFF4mSjfXz_d1gA73ALTnN_LaaGKyidRR6azX9toY2-j7cUkfVcU1ggIhJ0cjK9oA4q1jF5mDob6bdlDp4yaWHZKxxev-zjUQBqTk=@protonmail.com>
In-Reply-To: <zl3fWujFF4mSjfXz_d1gA73ALTnN_LaaGKyidRR6azX9toY2-j7cUkfVcU1ggIhJ0cjK9oA4q1jF5mDob6bdlDp4yaWHZKxxev-zjUQBqTk=@protonmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <202208041935.14223.luke@dashjr.org>
Subject: Re: [bitcoin-dev] RBF rules,
	setting policy defaults in Bitcoin Core and the role of BIPs
Precedence: list

Policy is a subjective per-node, not systemic, not enforcable or expectable=
,=20
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 "thi=
s=20
is the policy I would like you to apply to potential replacements of these=
=20
transactions". Whether the nodes abide this request or not, the purpose and=
=20
justification of the BIP is to standardize the communication of it.

Since BIP125 is widely implemented, it should not be changed except for=20
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 b=
e=20
written that is distinguishable from BIP125 (perhaps drop the sequence numb=
er=20
by 1 more). However, unless nodes are going to honour both the BIP125-reque=
st=20
policy *and* a new policy, it might be simpler for them to just not honour=
=20
the requested BIP125 policy exactly.

Also note that security should NEVER depend on assumptions of node policies=
=2E=20
Doing so would be a serious security vulnerability, regardless of what actu=
al=20
network policies are. It's fine to blame nodes/miners if they single out yo=
ur=20
transactions, but if it's just a matter of a general policy your transactio=
ns=20
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=E2=80=99m 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=E2=80=99t ideal but mistakes happen and will con=
tinue to
> happen. I certainly do not intend any criticism whatsoever to any of the
> individuals involved. Thankfully this discrepancy doesn=E2=80=99t 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=E2=80=99t 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 ha=
ve
> 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 t=
he
> 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 (BI=
P)
> and a reference implementation (Bitcoin Core) I think the norm for materi=
al
> 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=E2=80=99t matter th=
at 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. F=
or
> consensus PRs this clearly doesn=E2=80=99t make sense. Many of us have an=
d 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=E2=80=99t be the case) relying on the=
m.
>
> 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=E2=
=80=99t
> 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 c=
an
> 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 strivi=
ng
> to do better and be more rigorous than whatever the standard was in 2015.
> But I don=E2=80=99t work on policy in Core full time and it is very possi=
ble that
> there are subtleties that I=E2=80=99m 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.h=
tm
>l
>
> [3]:
> https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replace=
me
>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