path: root/09/b290cd48dc713cb0cac277cdd5167207caf25e

Return-Path: <michaelfolkson@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A85FFC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Aug 2022 21:47:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 701EA82F77
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Aug 2022 21:47:26 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 701EA82F77
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
 header.a=rsa-sha256 header.s=protonmail3 header.b=qu5VhEan
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 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, FREEMAIL_FROM=0.001,
 SPF_HELO_PASS=-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 bhVzeqDS6P8O
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Aug 2022 21:47:25 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 5464C82F32
Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 5464C82F32
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Aug 2022 21:47:24 +0000 (UTC)
Date: Thu, 04 Aug 2022 21:47:08 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1659649641; x=1659908841;
 bh=Bp6L9xwcFmpxh4ONt/MSfWuzPGDSVVIUfHhXD4i2ZP8=;
 h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
 References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To:
 Feedback-ID:Message-ID;
 b=qu5VhEannm6b1oZmn58DnC6/6x9dtcRy8yLZCg3SyPXR1p4jwTd5sNQyyqUEMyulv
 wXXnwQUMfNQen3aIvwwyV5YQRXnWHH0N4cAb+Zvz1tM7Pom7g3uN2DieMTYKhBG/fY
 mB/ADsrNY+OljMzcl9AdzvEy6NU0N4Ncokln+Dw3P3FDCXuOjjp9M8hOxxShfCOpQL
 HYfuybbtPWyAs9WT8S4QJJczBWLib9VB1dIgCk+7SDVewALGnN/45GK334WBYGoj1t
 mq3GfaRMPDBAUJkkzfKMNR6t10c3YIp9bgRyB96yH6GsknEqFCjQL2wdZJJeM3TNIG
 92oxnVxgAZLrg==
To: Luke Dashjr <luke@dashjr.org>
From: Michael Folkson <michaelfolkson@protonmail.com>
Reply-To: Michael Folkson <michaelfolkson@protonmail.com>
Message-ID: <WpuGECly2HymYFQCo_0Ahoyfv0osOpoMLZS-TkNLyg9iC4cLdHiP-ULm7QkSRlL4Xvg3UUq5FAkTBkcihHb0fHZc3im9EQNRumGNY40XJ68=@protonmail.com>
In-Reply-To: <202208041935.14223.luke@dashjr.org>
References: <zl3fWujFF4mSjfXz_d1gA73ALTnN_LaaGKyidRR6azX9toY2-j7cUkfVcU1ggIhJ0cjK9oA4q1jF5mDob6bdlDp4yaWHZKxxev-zjUQBqTk=@protonmail.com>
 <202208041935.14223.luke@dashjr.org>
Feedback-ID: 27732268:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 04 Aug 2022 23:32:31 +0000
Cc: bitcoin-dev@lists.linuxfoundation.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 21:47:26 -0000

Thanks for this Luke.

> Since BIP125 is widely implemented, it should not be changed except for c=
orrections to things which are errors deviating from the original intent.

In this example the BIP125/RBF rules implemented in Core are (and always ha=
ve been) different to the rules as described in BIP125. As far as I know ot=
her 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 im=
plemented in Core and future intended changes to how RBF rules are implemen=
ted in Core which may or may not also be in a state of flux. I take the vie=
w that once those new RBF rules are "finalized" there should be a new BIP b=
ut others disagree.

> Also note that security should NEVER depend on assumptions of node polici=
es. 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 o=
ne do when setting default policy rules in the dominant implementation on t=
he network? I think you lean towards not factoring that in whatsoever to de=
cisions on default policy rules whereas (perhaps mistakenly) I lean towards=
 factoring that in to default policy rule decisions especially when there d=
on't seem to be many other factors to consider. In the case of Lightning Ne=
twork I think we both want it to succeed and hopefully in the long term def=
ault 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 expectab=
le,
> 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 "t=
his
> is the policy I would like you to apply to potential replacements of thes=
e
> transactions". Whether the nodes abide this request or not, the purpose a=
nd
> 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 nu=
mber
> by 1 more). However, unless nodes are going to honour both the BIP125-req=
uest
> 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 polici=
es.
> Doing so would be a serious security vulnerability, regardless of what ac=
tual
> 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 transact=
ions
> 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 we=
re merged
> > into Bitcoin Core in November 2015 0. Following that merge David Hardin=
g
> > and Peter Todd drafted a BIP (BIP125 1) outlining the RBF rules that ha=
d
> > been implemented in Bitcoin Core. The rationales for the rules in the B=
IP
> > 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 som=
e
> > 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 outline=
d in
> > BIP125. Clearly this isn=E2=80=99t ideal but mistakes happen and will c=
ontinue to
> > happen. I certainly do not intend any criticism whatsoever to any of th=
e
> > 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 an=
d
> > allowed for a post mortem on why the implementation didn=E2=80=99t matc=
h 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 th=
e
> > mistakes made with BIP125 by having a BIP that does correctly outline t=
he
> > 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 securit=
y
> > 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 th=
e
> > 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 review=
ed
> > 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 mate=
rial
> > step change policy changes should be a specification (BIP) and a refere=
nce
> > 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. Bu=
t
> > with L2 protocol security to some extent relying on policy whether we l=
ike
> > 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, Approa=
ch
> > ACKs and then code review, testing ACKs in that order. The reason for t=
his
> > 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 =
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=E2=80=99t make sense. Many of us have =
and continue
> > to cross check the Taproot BIPs with the Taproot reference implementati=
on
> > 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 t=
hem.
> >
> > 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 ar=
e 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=
 can
> > get comfortable with? Or is a new static set of RBF rules close to bein=
g
> > finalized and there is just an aversion to using BIPs and a specificati=
on?
> >
> > Generally, as time passes, the ecosystem grows, layers on top of the ba=
se
> > 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 stri=
ving
> > to do better and be more rigorous than whatever the standard was in 201=
5.
> > But I don=E2=80=99t work on policy in Core full time and it is very pos=
sible that
> > there are subtleties that I=E2=80=99m entirely missing here. I think th=
is is the
> > right forum to ask about those subtleties though. Thanks to those who w=
ork
> > 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