path: root/5a/abc4073edcdc46c71c70cd7cee130456734f12

Return-Path: <antoine.riard@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 01CC4C000B;
 Fri, 18 Jun 2021 22:11:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id D79DD83CAE;
 Fri, 18 Jun 2021 22:11:54 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
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 3MYwViswf2o5; Fri, 18 Jun 2021 22:11:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com
 [IPv6:2a00:1450:4864:20::42b])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 8F95683B1F;
 Fri, 18 Jun 2021 22:11:52 +0000 (UTC)
Received: by mail-wr1-x42b.google.com with SMTP id e22so8712565wrc.1;
 Fri, 18 Jun 2021 15:11:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=0h8YVxoNz3N1US4zLy/SxjA+agjnnH9Js7q5kUbsPCk=;
 b=G/UKJs7MWWp9myLvt1u/fd0QpK15zAn7dd3J9sEXyKAH9X9rTe/Wst2lze4QqTXaIa
 RjEou/dzn8o5eyorhzqRrwZy7dm/2Fh1kkcbDKVFj3H1S7BXiSD6QuyOko2YWRZqLrxZ
 AgUq5g2Gjr1fUeNGPtWuNP4Z2TqZ5/WCQzz/sxasUOMZANTRxM1Nthtc1IQ+jyDWIWI1
 gO3VSx7Mz1UFhyXtIYHsgNDuDsG4bOSfrrcHbCLwHvPBkbyI5fyW2X7TYzVUrzZlbWGr
 46UFGuFGWfDkS6ojSWdCRauLNeIU50jYeLlqZiAWZIhacjQuAtd2cSIVDdgv68GJiOcv
 715g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=0h8YVxoNz3N1US4zLy/SxjA+agjnnH9Js7q5kUbsPCk=;
 b=rzQziDHAvAfnuB4lJfOjhympG/lQx1FqaK/LmugWbU+NuFBsuLCICL5Gn8ovnmf/Yg
 UhlTsvY+4NUKm4iSke17vq636PI5xX0e7YuCi8F3nC/t/hA4wTUKQWKL+BqLIXBITLNy
 RZuEDmVNAgFVGwXJyB47UWtZvC5k0XCJJkNIB8nKfmWsRqLAWI9u5xF/s8686b6E4tFf
 H+oBbtHQf5tHD9P2Th+RZuCxu/riLpQwq/cCFcHAe0AizkZCh9q3D/q4COYuqqEf+YZD
 y9MUCMiPdc7VgsbM8GVADh1PPvcGDXgsNKkYmCzPk9qZYtTI12qNDcp8CiYeI13s7vZC
 KVXw==
X-Gm-Message-State: AOAM532NJTWhnkErKxOOShlLc9mTOGByulFdwhbhUMj0WaCsBRFODa1M
 RGdYMD6jGRrdP0O/AwQwmwqkDZ/pbmaOjDa3r//qT8yekiE=
X-Google-Smtp-Source: ABdhPJzQ5tU+QWIgosya1SaMmbQ0kMcLwYyAdnQTBJCV/1pnX73KDuu52wissnsYWaclnPHI+FcHgL8liOHKrMTwEUA=
X-Received: by 2002:adf:ee4e:: with SMTP id w14mr15244913wro.14.1624054310391; 
 Fri, 18 Jun 2021 15:11:50 -0700 (PDT)
MIME-Version: 1.0
From: Antoine Riard <antoine.riard@gmail.com>
Date: Fri, 18 Jun 2021 18:11:38 -0400
Message-ID: <CALZpt+FF_TT_K3wjWhhaDE6Ue=RAsM2JWO7-mYjm5LtHqJvNmg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, 
 "lightning-dev\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000004452ba05c5119cbc"
X-Mailman-Approved-At: Fri, 18 Jun 2021 22:16:16 +0000
Subject: [bitcoin-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages
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: Fri, 18 Jun 2021 22:11:55 -0000

--0000000000004452ba05c5119cbc
Content-Type: text/plain; charset="UTF-8"

Hi,

It's a big chunk, so if you don't have time browse parts 1 and 2 and share
your 2 sats on the deployment timeline :p

This post recalls some unsolved safety holes about Lightning, how
package-relay or SIGHASH_ANYPREVOUT can solve the first one, how a mempool
hardening can solve the second one, few considerations on package-relay
design trade-offs and propose a rough deployment timeline.

1) Lightning Safety Holes : Pre-Signed Feerate and Tx-Pinning (to skip if
you're a LN dev)

As of today, Lightning is suffering from 2 safety holes w.r.t to base-layer
interactions, widely discussed among ln devs.

The first one, the pre-signed feerate issue with future broadcasted
time-sensitive transactions is laid out clearly in Matt Corallo's "CPFP
Carve-Out Fee-Prediction Issues in Contracting Applications (eg Lightning)"
[0]. This issue might provoke loss of funds, even in non-adversarial
settings, i.e a Lightning routing hub not being able to settle backward
onchain a successful HTLC during occurrences of sudden mempool congestion.

As blockspace demand increases with an always growing number of
onchain/offchain bitcoin users, coupling effects are more likely to happen
and this pre-signed feerate issue is going to become more urgent to solve
[1]. For e.g, few percentiles of increases in feerate being overpriced by
Lightning routing hubs to close "fractional-reserve" backed anchor
channels, driving mempools congestions, provoking anchor channels
fee-bumping reserves becoming even more under-provisioned and thus close
down, etc.

The second issue, malicious transaction pinnings, is documented in Bastien
Teinturier's "Pinning Attacks" [2]. AFAIK, there is a rough consensus among
devs on the conceptual feasibility of such a class of attacks against a LN
node, though so far we have not seen them executed in the wild and I'm not
aware of anyone having realized them in real-world conditions. Note, there
is a variety of attack scenarios to consider which is function of a wide
matrix (channel types, LN implementation's `update_fee` policy, LN
implementation's `cltv_delta` policy, mempool congestion feerate groups,
routing hubs or end nodes) Demoing against deployed LN implementations with
default settings has been on my todo for a while, though a priori One
Scenario To Exploit Them All doesn't fit well.

Side-note, as a LN operator, if you're worried about those security risks,
you can bump your `cltv_delta`/`cltv_expiry_delta` to significantly coarse
the attacks.

I think there is an important point to underscore. Considering the state of
knowledge we have today, I believe there is no strong interdependency
between solving pre-signed feerate and tx-pinning with the same mechanism
from a safety/usability standpoint. Or last such mechanism can be deployed
by stages.

2) Solving the Pre-Signed Feerate problem : Package-Relay or
SIGHASH_ANYPREVOUT

For Lightning, either package-relay or SIGHASH_ANYPREVOUT should be able to
solve the pre-signed feerate issue [3]

One of the interesting points recalled during the first transaction relay
workshops was that L2s making unbounded security assumptions on
non-normative tx-relay/mempool acceptance rules sounds a wrong direction
for the Bitcoin ecosystem long-term, and more prone to subtle bugs/safety
risks across the ecosystem.

I did express the contrary, public opinion a while back [4]. That said, I
start to agree it's wiser ecosystem-wise to keep those non-normatives rules
as only a groundwork for weaker assumptions than consensus ones. Though it
would be nice for long-term L2s stability to consider them with more care
than today in our base-layer protocol development process [4]

On this rational, I now share the opinion it's better long-term to solve
the pre-signed feerate problem with a consensus change such as
SIGHASH_ANYPREVOUT rather than having too much off-chain coins relying on
the weaker assumptions offered by bitcoin core's tx-relay/mempool
acceptance rules, and far harder to replicate and disseminate across the
ecosystem.

However, if SIGHASH_ANYPREVOUT is Things Done Right(tm), should we discard
package-relay ?

Sadly, in the worst-case scenario we might never reach consensus again
across the ecosystem and Taproot is the last softfork. Ever :/ *sad violons
and tissues jingle*

With this dilemma in mind, it might be wise for the LN/L2 ecosystems to
have a fall-back plan to solve their safety/usability issues and
package-relay sounds a reasonable, temporary "patch".

Even if package-relay requires serious engineering effort in Bitcoin Core
to avoid introducing new DoSes, swallowing well the complexity increase in
critical code paths such as the mempool/p2p stack and a gentle API design
for our friends the L2 devs, I believe it's worthy the engineering
resources cost. From-my-completely-biased-LN-dev viewpoint :p

In the best-case scenario, we'll activate SIGHASH_ANYPREVOUT and better
fee-bumping primitives softforks [5] slowly strip off the "L2 fee-bumping
primitive" semantic from "package-relay", friendly nudge the L2 ecosystem
to seat their fee-bumping on safer, consensus assumptions and maybe keep
the p2p packages to improve on the malicious mempool-partitions-side or as
a replacement of our orphan logic.

3) Solving Tx-Pinnings : Hardening the Mempool against Tx-Relay Jammings
attacks

Current Mempool anti-DoS rules have been mostly designed at a time where
the shared-utxo model with competing time-sensitive transactions was still
an idea on the whiteboard. The last few years have revealed those anti-DoS
rules as a source of security vulnerabilities for Lightning and a research
concern for L2s still in the early-phase of deployment [6].

Beyond real-world pinning exercises against production software as a
complement of the current pinning attacks research, it would be better to
agree on a common L2 attacker model before to modify widely-relied subset
of the mempool, such as the replace-by-fee logic or the in-mempool package
limits [7]. One risk of uncareful changes in this area would be to solve a
pinning vector for a L2-alice but introduce a new vuln for a L2-bob.

I believe the first part of such a revamp could hopefully land somehow next
year. Though, IMHO, in the years to come, we'll have to do more hard
reasoning to ensure the mempool supports advanced Bitcoin protocols (e.g
OP_CTV congestion tree,  CoinPool, interactive cut-through, ...)

Note the opinion I raised above on quality of assumptions on mempool
behavior, even if we harden it on the base-layer side,  L2s should be
well-aware the product is shipped with a guarantee limitation :p

4) Considerations on Package-Relay Design

Package relay relies on at least two cleanly separate components (awesome,
if we schedule to deprecate the higher half in the future!)
* "the higher half" : extension of the mempool logic, with a new
package-level policy, not strictly intersecting with the tx-level policy
* "the lower half" : at least three different designs, receiver initiated,
sender-initiated and relay-initiated

One open design question for the "higher half" is the package-size of the
acceptance logic, which is ultimately a function of the L2 ecosystem state.
Do we have deployed or in deployment phase L2 protocols with a need for
more than 2-stage and if yes what API bounds do they expect ? That's a
question I hope we'll gather feedback during next Thursday's transaction
relay workshops. IMO, such package API should come out with a specification
on which L2-community can be gathered and public consensus established. For
the same communications reasons towards downstream projects, we have a
BIP125 standard. And especially in this case the bitcoin core protocol
development process should carefully listen to the needs of actual L2
users. Also, a lot of those L2 devs, they don't speak C++ :)

One could imagine those mempool standards as "perishable" contracts between
a base-layer implementation and the upper layers, with ultimately the
full-node implementation reserving itself the right to deprecate them,
maybe with a lengthy-warning period ?

Beyond that, I believe there is another remaining interdependency between
"the lower half" design and L2s behaviors, namely bandwidth waste in case
of a high-frequency of package redundancy. Let's say if a package is
composed of {A, B}, and the package broadcaster fee-bump, triggering the
transformation to {A, B'}, A bandwidth at first propagation is going to be
wasted. Note, if we assume a dynamic fee-market, this package rebroadcast
behavior should be common across the ecosystem. Though ultimately, the
seriousness of this issue is going to be a function of the number of
Lightning nodes relying on base-layer tx-relay and the number of fee-bumped
onchain operations per Lightning node.

I believe it would be great to come up with simulations on this front, just
to avoid silently nullifying all the tedious, small improvements which have
been done in the last years to minimize bitcoin core node's bandwidth.

Another alternative would be to come with a cost-effective
package-replacement policy, so likely more complexity. But might it not
make sense to not economically outlaw Lightning nodes with a small fee
budget ?

Lastly, there is a consideration to have around anti-DoS measures we'll
have to deploy for package-relay. Too easy, and that's a security concern
for the base-layer, too hard, and that's introducing yet-another tx-relay
jamming vector against L2, this time at the p2p layer (though won't be the
first time [8]

In any-case we should carefully consider the upgradeability of
package-relay v.0, like if we upgrade some components of it such as package
format or package-announcement scheme.

So yeah why not early 0.24 ? Maybe a bit too short with all those p2p
questions to clear up among core devs. Ideally, we would land in the
beginning/middle of the cycle to have time for beta-testing on the L2-side
and share feedback.

Though ultimately, this question of p2p design belongs to the bitcoin core
dev process.

# Deployment timeline

So what I believe as a rough deployment timeline.

* "package-relay" in bitcoin core, early 0.24 or 0.25: a Core's release
cycle offered to the LN/L2 ecosystem to integrate/exercise/provide feedback
on package API

* "mempool hardening" in bitcoin core, early 0.26 or 0.27, a Core's release
cycle offered to the whole Bitcoin ecosystem to adapt their Bitcoin
clients, maybe with a boolean setting to smooth the new policy deployment

* SIGHASH_ANYPREVOUT softfork in the coming year(s), opt-in of any LN/L2
implementation to migrate its fee-bumping backend on top of it

* "optimized/multi-party fee-bumping primitive" softfork (one of tx
mutation/sigash_iomap/sponsorship proposals) softfork in the coming decade,
friendly uplift of the L2 ecosystem

Glad to answer any unclarity or uncorrectness of mine :)

Cheers,
Antoine,

[0] see
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html

[1] "The Coupling Principle states that as things get larger, they often
exhibit increased interdependence between components".

[2] see
https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md

[2] see "Advances in Bitcoin Contracting : Uniform Policy and Package
Relay"
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-July/018063.html

[3] I don't think there is a clear discussion on how SIGHASH_ANYPREVOUT
solves pinnings beyond those LN meetings logs:
https://gnusha.org/lightning-dev/2020-06-08.log

[4] And I believe such great example has been done with this recent change
proposed for bitcoin core addr-relay policy:
https://github.com/bitcoin/bitcoin/pull/21528#issuecomment-809906430, where
the PR author did bear the burden of reaching out potentially affected
downstream projects.

[5] Like one of tx_mutation/sighash_iomap/sponsorship proposal proposed in
the thread "A Stroll through Fee-Bumping Techniques: Input-based vs
Child-Pay-for-Parent" :
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/019031.html

[6] For a discussion about fee-bumping issues for L2s extended beyond LN
see the analysis of the Revault protocol :
https://arxiv.org/pdf/2102.09392.pdf

[7] As a WIP towards establishing an attacker model, see "Secure
Fee-Bumping for L2s"
https://bitcoin-problems.github.io/problems/fee-bumping.html

[8] Tx-relay rules as a concern for second-layers has been raised early on,
at least during p2p segwit review
https://github.com/bitcoin/bitcoin/issues/8279

--0000000000004452ba05c5119cbc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Hi,<br><br>It&#39;s a big chunk, so if you don&#=
39;t have time browse parts 1 and 2 and share your 2 sats on the deployment=
 timeline :p<br><br>This post recalls some unsolved safety holes about Ligh=
tning, how package-relay or SIGHASH_ANYPREVOUT can solve the first one, how=
 a mempool hardening can solve the second one, few considerations on packag=
e-relay design trade-offs and propose a rough deployment timeline.<br><br>1=
) Lightning Safety Holes : Pre-Signed Feerate and Tx-Pinning (to skip if yo=
u&#39;re a LN dev)<br><br>As of today, Lightning is suffering from 2 safety=
 holes w.r.t to base-layer interactions, widely discussed among ln devs.<br=
><br>The first one, the pre-signed feerate issue with future broadcasted ti=
me-sensitive transactions is laid out clearly in Matt Corallo&#39;s &quot;C=
PFP Carve-Out Fee-Prediction Issues in Contracting Applications (eg Lightni=
ng)&quot; [0]. This issue might provoke loss of funds, even in non-adversar=
ial settings, i.e a Lightning routing hub not being able to settle backward=
 onchain a successful HTLC during occurrences of sudden mempool congestion.=
<br><br>As blockspace demand increases with an always growing number of onc=
hain/offchain bitcoin users, coupling effects are more likely to happen and=
 this pre-signed feerate issue is going to become more urgent to solve [1].=
 For e.g, few percentiles of increases in feerate being overpriced by Light=
ning routing hubs to close &quot;fractional-reserve&quot; backed anchor cha=
nnels, driving mempools congestions, provoking anchor channels fee-bumping =
reserves becoming even more under-provisioned and thus close down, etc.<br>=
<br>The second issue, malicious transaction pinnings, is documented in Bast=
ien Teinturier&#39;s &quot;Pinning Attacks&quot; [2]. AFAIK, there is a rou=
gh consensus among devs on the conceptual feasibility of such a class of at=
tacks against a LN node, though so far we have not seen them executed in th=
e wild and I&#39;m not aware of anyone having realized them in real-world c=
onditions. Note, there is a variety of attack scenarios to consider which i=
s function of a wide matrix (channel types, LN implementation&#39;s `update=
_fee` policy, LN implementation&#39;s `cltv_delta` policy, mempool congesti=
on feerate groups, routing hubs or end nodes) Demoing against deployed LN i=
mplementations with default settings has been on my todo for a while, thoug=
h a priori One Scenario To Exploit Them All doesn&#39;t fit well.<br><br>Si=
de-note, as a LN operator, if you&#39;re worried about those security risks=
, you can bump your `cltv_delta`/`cltv_expiry_delta` to significantly coars=
e the attacks.<br><br>I think there is an important point to underscore. Co=
nsidering the state of knowledge we have today, I believe there is no stron=
g interdependency between solving pre-signed feerate and tx-pinning with th=
e same mechanism from a safety/usability standpoint. Or last such mechanism=
 can be deployed by stages.<br><br>2) Solving the Pre-Signed Feerate proble=
m : Package-Relay or SIGHASH_ANYPREVOUT<br><br>For Lightning, either packag=
e-relay or SIGHASH_ANYPREVOUT should be able to solve the pre-signed feerat=
e issue [3]<br><br>One of the interesting points recalled during the first =
transaction relay workshops was that L2s making unbounded security assumpti=
ons on non-normative tx-relay/mempool acceptance rules sounds a wrong direc=
tion for the Bitcoin ecosystem long-term, and more prone to subtle bugs/saf=
ety risks across the ecosystem.<br><br>I did express the contrary, public o=
pinion a while back [4]. That said, I start to agree it&#39;s wiser ecosyst=
em-wise to keep those non-normatives rules as only a groundwork for weaker =
assumptions than consensus ones. Though it would be nice for long-term L2s =
stability to consider them with more care than today in our base-layer prot=
ocol development process [4]<br><br>On this rational, I now share the opini=
on it&#39;s better long-term to solve the pre-signed feerate problem with a=
 consensus change such as SIGHASH_ANYPREVOUT rather than having too much of=
f-chain coins relying on the weaker assumptions offered by bitcoin core&#39=
;s tx-relay/mempool acceptance rules, and far harder to replicate and disse=
minate across the ecosystem.<br><br>However, if SIGHASH_ANYPREVOUT is Thing=
s Done Right(tm), should we discard package-relay ?<br><br>Sadly, in the wo=
rst-case scenario we might never reach consensus again across the ecosystem=
 and Taproot is the last softfork. Ever :/ *sad violons and tissues jingle*=
<br><br>With this dilemma in mind, it might be wise for the LN/L2 ecosystem=
s to have a fall-back plan to solve their safety/usability issues and packa=
ge-relay sounds a reasonable, temporary &quot;patch&quot;.<br><br>Even if p=
ackage-relay requires serious engineering effort in Bitcoin Core to avoid i=
ntroducing new DoSes, swallowing well the complexity increase in critical c=
ode paths such as the mempool/p2p stack and a gentle API design for our fri=
ends the L2 devs, I believe it&#39;s worthy the engineering resources cost.=
 From-my-completely-biased-LN-dev viewpoint :p<br><br>In the best-case scen=
ario, we&#39;ll activate SIGHASH_ANYPREVOUT and better fee-bumping primitiv=
es softforks [5] slowly strip off the &quot;L2 fee-bumping primitive&quot; =
semantic from &quot;package-relay&quot;, friendly nudge the L2 ecosystem to=
 seat their fee-bumping on safer, consensus assumptions and maybe keep the =
p2p packages to improve on the malicious mempool-partitions-side or as a re=
placement of our orphan logic.<br><br>3) Solving Tx-Pinnings : Hardening th=
e Mempool against Tx-Relay Jammings attacks<br><br>Current Mempool anti-DoS=
 rules have been mostly designed at a time where the shared-utxo model with=
 competing time-sensitive transactions was still an idea on the whiteboard.=
 The last few years have revealed those anti-DoS rules as a source of secur=
ity vulnerabilities for Lightning and a research concern for L2s still in t=
he early-phase of deployment [6].<br><br>Beyond real-world pinning exercise=
s against production software as a complement of the current pinning attack=
s research, it would be better to agree on a common L2 attacker model befor=
e to modify widely-relied subset of the mempool, such as the replace-by-fee=
 logic or the in-mempool package limits [7]. One risk of uncareful changes =
in this area would be to solve a pinning vector for a L2-alice but introduc=
e a new vuln for a L2-bob.<br><br>I believe the first part of such a revamp=
 could hopefully land somehow next year. Though, IMHO, in the years to come=
, we&#39;ll have to do more hard reasoning to ensure the mempool supports a=
dvanced Bitcoin protocols (e.g OP_CTV congestion tree,=C2=A0 CoinPool, inte=
ractive cut-through, ...)<br><br>Note the opinion I raised above on quality=
 of assumptions on mempool behavior, even if we harden it on the base-layer=
 side,=C2=A0 L2s should be well-aware the product is shipped with a guarant=
ee limitation :p<br><br>4) Considerations on Package-Relay Design<br><br>Pa=
ckage relay relies on at least two cleanly separate components (awesome, if=
 we schedule to deprecate the higher half in the future!)<br>* &quot;the hi=
gher half&quot; : extension of the mempool logic, with a new package-level =
policy, not strictly intersecting with the tx-level policy<br>* &quot;the l=
ower half&quot; : at least three different designs, receiver initiated, sen=
der-initiated and relay-initiated<br><br></div>One open design question for=
 the &quot;higher half&quot; is the package-size of the acceptance logic, w=
hich is ultimately a function of the L2 ecosystem state. Do we have deploye=
d or in deployment phase L2 protocols with a need for more than 2-stage and=
 if yes what API bounds do they expect ? That&#39;s a question I hope we&#3=
9;ll gather feedback during next Thursday&#39;s transaction relay workshops=
. IMO, such package API should come out with a specification on which L2-co=
mmunity can be gathered and public consensus established. For the same comm=
unications reasons towards downstream projects, we have a BIP125 standard. =
And especially in this case the bitcoin core protocol development process s=
hould carefully listen to the needs of actual L2 users. Also, a lot of thos=
e L2 devs, they don&#39;t speak C++ :)<br></div><div><br>One could imagine =
those mempool standards as &quot;perishable&quot; contracts between a base-=
layer implementation and the upper layers, with ultimately the full-node im=
plementation reserving itself the right to deprecate them, maybe with a len=
gthy-warning period ?<br><br>Beyond that, I believe there is another remain=
ing interdependency between &quot;the lower half&quot; design and L2s behav=
iors, namely bandwidth waste in case of a high-frequency of package redunda=
ncy. Let&#39;s say if a package is composed of {A, B}, and the package broa=
dcaster fee-bump, triggering the transformation to {A, B&#39;}, A bandwidth=
 at first propagation is going to be wasted. Note, if we assume a dynamic f=
ee-market, this package rebroadcast behavior should be common across the ec=
osystem. Though ultimately, the seriousness of this issue is going to be a =
function of the number of Lightning nodes relying on base-layer tx-relay an=
d the number of fee-bumped onchain operations per Lightning node.<br><br>I =
believe it would be great to come up with simulations on this front, just t=
o avoid silently nullifying all the tedious, small improvements which have =
been done in the last years to minimize bitcoin core node&#39;s bandwidth.<=
br><br>Another alternative would be to come with a cost-effective package-r=
eplacement policy, so likely more complexity. But might it not make sense t=
o not economically outlaw Lightning nodes with a small fee budget ?<br><br>=
Lastly, there is a consideration to have around anti-DoS measures we&#39;ll=
 have to deploy for package-relay. Too easy, and that&#39;s a security conc=
ern for the base-layer, too hard, and that&#39;s introducing yet-another tx=
-relay jamming vector against L2, this time at the p2p layer (though won&#3=
9;t be the first time [8]<br><br>In any-case we should carefully consider t=
he upgradeability of package-relay v.0, like if we upgrade some components =
of it such as package format or package-announcement scheme.<br><br>So yeah=
 why not early 0.24 ? Maybe a bit too short with all those p2p questions to=
 clear up among core devs. Ideally, we would land in the beginning/middle o=
f the cycle to have time for beta-testing on the L2-side and share feedback=
.<br><br>Though ultimately, this question of p2p design belongs to the bitc=
oin core dev process.<br><br># Deployment timeline<br><br>So what I believe=
 as a rough deployment timeline.<br><br>* &quot;package-relay&quot; in bitc=
oin core, early 0.24 or 0.25: a Core&#39;s release cycle offered to the LN/=
L2 ecosystem to integrate/exercise/provide feedback on package API<br><br>*=
 &quot;mempool hardening&quot; in bitcoin core, early 0.26 or 0.27, a Core&=
#39;s release cycle offered to the whole Bitcoin ecosystem to adapt their B=
itcoin clients, maybe with a boolean setting to smooth the new policy deplo=
yment<br><br>* SIGHASH_ANYPREVOUT softfork in the coming year(s), opt-in of=
 any LN/L2 implementation to migrate its fee-bumping backend on top of it<b=
r><br>* &quot;optimized/multi-party fee-bumping primitive&quot; softfork (o=
ne of tx mutation/sigash_iomap/sponsorship proposals) softfork in the comin=
g decade, friendly uplift of the L2 ecosystem<br><br>Glad to answer any unc=
larity or uncorrectness of mine :)<br><br>Cheers,<br>Antoine,<br><br>[0] se=
e <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-N=
ovember/016518.html" target=3D"_blank">https://lists.linuxfoundation.org/pi=
permail/bitcoin-dev/2018-November/016518.html</a><br><br>[1] &quot;The Coup=
ling Principle states that as things get larger, they often exhibit increas=
ed interdependence between components&quot;.<br><br>[2] see <a href=3D"http=
s://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md" target=
=3D"_blank">https://github.com/t-bast/lightning-docs/blob/master/pinning-at=
tacks.md</a><br><br>[2] see &quot;Advances in Bitcoin Contracting : Uniform=
 Policy and Package Relay&quot; <a href=3D"https://lists.linuxfoundation.or=
g/pipermail/bitcoin-dev/2020-July/018063.html" target=3D"_blank">https://li=
sts.linuxfoundation.org/pipermail/bitcoin-dev/2020-July/018063.html</a><br>=
<br>[3] I don&#39;t think there is a clear discussion on how SIGHASH_ANYPRE=
VOUT solves pinnings beyond those LN meetings logs: <a href=3D"https://gnus=
ha.org/lightning-dev/2020-06-08.log" target=3D"_blank">https://gnusha.org/l=
ightning-dev/2020-06-08.log</a><br><br></div><div>[4] And I believe such gr=
eat example has been done with this recent change proposed for bitcoin core=
 addr-relay policy: <a href=3D"https://github.com/bitcoin/bitcoin/pull/2152=
8#issuecomment-809906430">https://github.com/bitcoin/bitcoin/pull/21528#iss=
uecomment-809906430</a>, where the PR author did bear the burden of reachin=
g out potentially affected downstream projects.<br></div><div><br>[5] Like =
one of tx_mutation/sighash_iomap/sponsorship proposal proposed in the threa=
d &quot;A Stroll through Fee-Bumping Techniques: Input-based vs Child-Pay-f=
or-Parent&quot; : <a href=3D"https://lists.linuxfoundation.org/pipermail/bi=
tcoin-dev/2021-May/019031.html" target=3D"_blank">https://lists.linuxfounda=
tion.org/pipermail/bitcoin-dev/2021-May/019031.html</a><br><br>[6] For a di=
scussion about fee-bumping issues for L2s extended beyond LN see the analys=
is of the Revault protocol : <a href=3D"https://arxiv.org/pdf/2102.09392.pd=
f" target=3D"_blank">https://arxiv.org/pdf/2102.09392.pdf</a><br><br>[7] As=
 a WIP towards establishing an attacker model, see &quot;Secure Fee-Bumping=
 for L2s&quot; <a href=3D"https://bitcoin-problems.github.io/problems/fee-b=
umping.html" target=3D"_blank">https://bitcoin-problems.github.io/problems/=
fee-bumping.html</a><br><br>[8] Tx-relay rules as a concern for second-laye=
rs has been raised early on, at least during p2p segwit review <a href=3D"h=
ttps://github.com/bitcoin/bitcoin/issues/8279" target=3D"_blank">https://gi=
thub.com/bitcoin/bitcoin/issues/8279</a><br></div></div>

--0000000000004452ba05c5119cbc--