path: root/49/5e6cbe9d6f36ac642bf828c57ef111170fef35

Return-Path: <luke@dashjr.org>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9F4FCC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Aug 2022 19:36:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 56AB8831AC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Aug 2022 19:36:47 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 56AB8831AC
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (1024-bit key) header.d=dashjr.org header.i=@dashjr.org
 header.a=rsa-sha256 header.s=zinan header.b=mScY1/31
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.401
X-Spam-Level: 
X-Spam-Status: No, score=-4.401 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001,
 RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 8m4qswJUDHL0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Aug 2022 19:36:45 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 2448A831A7
Received: from zinan.dashjr.org (zinan.dashjr.org [IPv6:2001:470:88ff:2f::1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 2448A831A7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Aug 2022 19:36:44 +0000 (UTC)
Received: from ishibashi.lan (unknown [12.151.133.18])
 (Authenticated sender: luke-jr)
 by zinan.dashjr.org (Postfix) with ESMTPSA id 6836238AD736;
 Thu,  4 Aug 2022 19:35:15 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan;
 t=1659641803; bh=0qAqWED/VlkdT20SaK35dphzwz6YIySoOarjFe447Vo=;
 h=From:To:Subject:Date:References:In-Reply-To;
 b=mScY1/31n4+9EAvXrJ+0hN7ZB+11AgqIMSY5dXsNWAkkTqh50nh3RW38QsRVRiW/s
 bxex/DgoJkBuIdGRo6cCDbPgwpeWmfEvTrtAM1HrNZSkLoIizd7VMCuwLQ4yxJITbr
 ec8QUL1T2VasdT/UYPfchjAVYY5+cxvM2lqYpis0=
X-Hashcash: 1:25:220804:bitcoin-dev@lists.linuxfoundation.org::Em9sqdzo/MOXbakr:1mc9
X-Hashcash: 1:25:220804:michaelfolkson@protonmail.com::gKXW1xS4QgLAaoFi:jQ1zb
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>
X-KMail-QuotePrefix: > 
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Aug 2022 19:36:47 -0000

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