MIME-Version: 1.0
References: <CALZpt+FF_TT_K3wjWhhaDE6Ue=RAsM2JWO7-mYjm5LtHqJvNmg@mail.gmail.com>
In-Reply-To: <CALZpt+FF_TT_K3wjWhhaDE6Ue=RAsM2JWO7-mYjm5LtHqJvNmg@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Fri, 18 Jun 2021 21:34:28 -0400
Message-ID: <CALZpt+FZWm=cV-RJTWgCQg4F+Jnbt=zSOsDpe8L4UCLe9SB-dA@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="000000000000a48a0005c5147135"
Subject: Re: [bitcoin-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages
Precedence: list

--000000000000a48a0005c5147135
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> That's a question I hope we'll gather feedback during next Thursday's
transaction relay workshops.

As someone kindly pointed out to me, workshop is happening Tuesday, June
22th. Not Thursday, mistake of mine :/


Le ven. 18 juin 2021 =C3=A0 18:11, Antoine Riard <antoine.riard@gmail.com> =
a
=C3=A9crit :

> Hi,
>
> It's a big chunk, so if you don't have time browse parts 1 and 2 and shar=
e
> 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 mempoo=
l
> 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 happe=
n
> 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 Bastie=
n
> Teinturier's "Pinning Attacks" [2]. AFAIK, there is a rough consensus amo=
ng
> devs on the conceptual feasibility of such a class of attacks against a L=
N
> node, though so far we have not seen them executed in the wild and I'm no=
t
> aware of anyone having realized them in real-world conditions. Note, ther=
e
> 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 wi=
th
> 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 coars=
e
> 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 deploye=
d
> 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 rul=
es
> as only a groundwork for weaker assumptions than consensus ones. Though i=
t
> 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 discar=
d
> 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 violo=
ns
> 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 i=
n
> 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 a=
s
> 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 stil=
l
> an idea on the whiteboard. The last few years have revealed those anti-Do=
S
> rules as a source of security vulnerabilities for Lightning and a researc=
h
> 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 packag=
e
> 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 stat=
e.
> 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 specificati=
on
> on which L2-community can be gathered and public consensus established. F=
or
> 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 b=
e
> 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-bump=
ed
> 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 whi=
ch
> have been done in the last years to minimize bitcoin core node's bandwidt=
h.
>
> 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 th=
e
> 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 packa=
ge
> 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-sid=
e
> and share feedback.
>
> Though ultimately, this question of p2p design belongs to the bitcoin cor=
e
> 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 feedba=
ck
> 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 Bitco=
in
> 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 decad=
e,
> 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/016=
518.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 chang=
e
> 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 i=
n
> 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.h=
tml
>
> [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
>

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

<div dir=3D"ltr"><div><div>&gt; That&#39;s a question I hope we&#39;ll gath=
er feedback during next Thursday&#39;s transaction relay workshops.<br><br>=
</div>As someone kindly pointed out to me, workshop is happening Tuesday, J=
une 22th. Not Thursday, mistake of mine :/<br><br></div><br></div><br><div =
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0ven. 18=
 juin 2021 =C3=A0=C2=A018:11, Antoine Riard &lt;<a href=3D"mailto:antoine.r=
iard@gmail.com">antoine.riard@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><=
div>Hi,<br><br>It&#39;s a big chunk, so if you don&#39;t have time browse p=
arts 1 and 2 and share your 2 sats on the deployment timeline :p<br><br>Thi=
s post recalls some unsolved safety holes about Lightning, how package-rela=
y or SIGHASH_ANYPREVOUT can solve the first one, how a mempool hardening ca=
n solve the second one, few considerations on package-relay design trade-of=
fs and propose a rough deployment timeline.<br><br>1) Lightning Safety Hole=
s : Pre-Signed Feerate and Tx-Pinning (to skip if you&#39;re a LN dev)<br><=
br>As of today, Lightning is suffering from 2 safety holes w.r.t to base-la=
yer interactions, widely discussed among ln devs.<br><br>The first one, the=
 pre-signed feerate issue with future broadcasted time-sensitive transactio=
ns is laid out clearly in Matt Corallo&#39;s &quot;CPFP Carve-Out Fee-Predi=
ction Issues in Contracting Applications (eg Lightning)&quot; [0]. This iss=
ue might provoke loss of funds, even in non-adversarial settings, i.e a Lig=
htning routing hub not being able to settle backward onchain a successful H=
TLC during occurrences of sudden mempool congestion.<br><br>As blockspace d=
emand increases with an always growing number of onchain/offchain bitcoin u=
sers, coupling effects are more likely to happen and this pre-signed feerat=
e issue is going to become more urgent to solve [1]. For e.g, few percentil=
es of increases in feerate being overpriced by Lightning routing hubs to cl=
ose &quot;fractional-reserve&quot; backed anchor channels, driving mempools=
 congestions, provoking anchor channels fee-bumping reserves becoming even =
more under-provisioned and thus close down, etc.<br><br>The second issue, m=
alicious transaction pinnings, is documented in Bastien Teinturier&#39;s &q=
uot;Pinning Attacks&quot; [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&#39;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 ma=
trix (channel types, LN implementation&#39;s `update_fee` policy, LN implem=
entation&#39;s `cltv_delta` policy, mempool congestion feerate groups, rout=
ing hubs or end nodes) Demoing against deployed LN implementations with def=
ault settings has been on my todo for a while, though a priori One Scenario=
 To Exploit Them All doesn&#39;t fit well.<br><br>Side-note, as a LN operat=
or, if you&#39;re worried about those security risks, you can bump your `cl=
tv_delta`/`cltv_expiry_delta` to significantly coarse the attacks.<br><br>I=
 think there is an important point to underscore. Considering the state of =
knowledge we have today, I believe there is no strong interdependency betwe=
en solving pre-signed feerate and tx-pinning with the same mechanism from a=
 safety/usability standpoint. Or last such mechanism can be deployed by sta=
ges.<br><br>2) Solving the Pre-Signed Feerate problem : Package-Relay or SI=
GHASH_ANYPREVOUT<br><br>For Lightning, either package-relay or SIGHASH_ANYP=
REVOUT should be able to solve the pre-signed feerate issue [3]<br><br>One =
of the interesting points recalled during the first transaction relay works=
hops was that L2s making unbounded security assumptions on non-normative tx=
-relay/mempool acceptance rules sounds a wrong direction for the Bitcoin ec=
osystem long-term, and more prone to subtle bugs/safety risks across the ec=
osystem.<br><br>I did express the contrary, public opinion a while back [4]=
. That said, I start to agree it&#39;s wiser ecosystem-wise to keep those n=
on-normatives rules as only a groundwork for weaker assumptions than consen=
sus ones. Though it would be nice for long-term L2s stability to consider t=
hem with more care than today in our base-layer protocol development proces=
s [4]<br><br>On this rational, I now share the opinion 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 off-chain coins relying o=
n the weaker assumptions offered by bitcoin core&#39;s tx-relay/mempool acc=
eptance rules, and far harder to replicate and disseminate across the ecosy=
stem.<br><br>However, if SIGHASH_ANYPREVOUT is Things Done Right(tm), shoul=
d we discard package-relay ?<br><br>Sadly, in the worst-case scenario we mi=
ght never reach consensus again across the ecosystem and Taproot is the las=
t softfork. Ever :/ *sad violons and tissues jingle*<br><br>With this dilem=
ma in mind, it might be wise for the LN/L2 ecosystems to have a fall-back p=
lan to solve their safety/usability issues and package-relay sounds a reaso=
nable, temporary &quot;patch&quot;.<br><br>Even if package-relay requires s=
erious engineering effort in Bitcoin Core to avoid introducing new DoSes, s=
wallowing well the complexity increase in critical code paths such as the m=
empool/p2p stack and a gentle API design for our friends the L2 devs, I bel=
ieve it&#39;s worthy the engineering resources cost. From-my-completely-bia=
sed-LN-dev viewpoint :p<br><br>In the best-case scenario, we&#39;ll activat=
e SIGHASH_ANYPREVOUT and better fee-bumping primitives softforks [5] slowly=
 strip off the &quot;L2 fee-bumping primitive&quot; semantic from &quot;pac=
kage-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 replacement of our orphan=
 logic.<br><br>3) Solving Tx-Pinnings : Hardening the Mempool against Tx-Re=
lay Jammings attacks<br><br>Current Mempool anti-DoS rules have been mostly=
 designed at a time where the shared-utxo model with competing time-sensiti=
ve transactions was still an idea on the whiteboard. The last few years hav=
e 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 deplo=
yment [6].<br><br>Beyond real-world pinning exercises against production so=
ftware 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-reli=
ed subset of the mempool, such as the replace-by-fee logic or the in-mempoo=
l package limits [7]. One risk of uncareful changes in this area would be t=
o solve a pinning vector for a L2-alice but introduce a new vuln for a L2-b=
ob.<br><br>I believe the first part of such a revamp could hopefully land s=
omehow next year. Though, IMHO, in the years to come, we&#39;ll have to do =
more hard reasoning to ensure the mempool supports advanced Bitcoin protoco=
ls (e.g OP_CTV congestion tree,=C2=A0 CoinPool, interactive cut-through, ..=
.)<br><br>Note the opinion I raised above on quality of assumptions on memp=
ool behavior, even if we harden it on the base-layer side,=C2=A0 L2s should=
 be well-aware the product is shipped with a guarantee limitation :p<br><br=
>4) Considerations on Package-Relay Design<br><br>Package relay relies on a=
t least two cleanly separate components (awesome, if we schedule to depreca=
te the higher half in the future!)<br>* &quot;the higher half&quot; : exten=
sion of the mempool logic, with a new package-level policy, not strictly in=
tersecting with the tx-level policy<br>* &quot;the lower half&quot; : at le=
ast three different designs, receiver initiated, sender-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, which is ultimately a fu=
nction of the L2 ecosystem state. Do we have deployed or in deployment phas=
e 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&#39;ll gather feedback du=
ring next Thursday&#39;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 towa=
rds 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&#39=
;t speak C++ :)<br></div><div><br>One could imagine those mempool standards=
 as &quot;perishable&quot; contracts between a base-layer implementation an=
d the upper layers, with ultimately the full-node implementation reserving =
itself the right to deprecate them, maybe with a lengthy-warning period ?<b=
r><br>Beyond that, I believe there is another remaining interdependency bet=
ween &quot;the lower half&quot; design and L2s behaviors, namely bandwidth =
waste in case of a high-frequency of package redundancy. Let&#39;s say if a=
 package is composed of {A, B}, and the package broadcaster fee-bump, trigg=
ering the transformation to {A, B&#39;}, A bandwidth at first propagation i=
s going to be wasted. Note, if we assume a dynamic fee-market, this package=
 rebroadcast behavior should be common across the ecosystem. Though ultimat=
ely, 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-bum=
ped onchain operations per Lightning node.<br><br>I believe it would be gre=
at to come up with simulations on this front, just to avoid silently nullif=
ying all the tedious, small improvements which have been done in the last y=
ears to minimize bitcoin core node&#39;s bandwidth.<br><br>Another alternat=
ive would be to come with a cost-effective package-replacement policy, so l=
ikely more complexity. But might it not make sense to not economically outl=
aw Lightning nodes with a small fee budget ?<br><br>Lastly, there is a cons=
ideration to have around anti-DoS measures we&#39;ll have to deploy for pac=
kage-relay. Too easy, and that&#39;s a security concern for the base-layer,=
 too hard, and that&#39;s introducing yet-another tx-relay jamming vector a=
gainst L2, this time at the p2p layer (though won&#39;t be the first time [=
8]<br><br>In any-case we should carefully consider the upgradeability of pa=
ckage-relay v.0, like if we upgrade some components of it such as package f=
ormat or package-announcement scheme.<br><br>So yeah why not early 0.24 ? M=
aybe a bit too short with all those p2p questions to clear up among core de=
vs. Ideally, we would land in the beginning/middle of the cycle to have tim=
e for beta-testing on the L2-side and share feedback.<br><br>Though ultimat=
ely, this question of p2p design belongs to the bitcoin core dev process.<b=
r><br># Deployment timeline<br><br>So what I believe as a rough deployment =
timeline.<br><br>* &quot;package-relay&quot; in bitcoin core, early 0.24 or=
 0.25: a Core&#39;s release cycle offered to the LN/L2 ecosystem to integra=
te/exercise/provide feedback on package API<br><br>* &quot;mempool hardenin=
g&quot; in bitcoin core, early 0.26 or 0.27, a Core&#39;s release cycle off=
ered to the whole Bitcoin ecosystem to adapt their Bitcoin clients, maybe w=
ith a boolean setting to smooth the new policy deployment<br><br>* SIGHASH_=
ANYPREVOUT softfork in the coming year(s), opt-in of any LN/L2 implementati=
on to migrate its fee-bumping backend on top of it<br><br>* &quot;optimized=
/multi-party fee-bumping primitive&quot; softfork (one of tx mutation/sigas=
h_iomap/sponsorship proposals) softfork in the coming decade, friendly upli=
ft of the L2 ecosystem<br><br>Glad to answer any unclarity or uncorrectness=
 of mine :)<br><br>Cheers,<br>Antoine,<br><br>[0] see <a href=3D"https://li=
sts.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html" ta=
rget=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/201=
8-November/016518.html</a><br><br>[1] &quot;The Coupling Principle states t=
hat as things get larger, they often exhibit increased interdependence betw=
een components&quot;.<br><br>[2] see <a href=3D"https://github.com/t-bast/l=
ightning-docs/blob/master/pinning-attacks.md" target=3D"_blank">https://git=
hub.com/t-bast/lightning-docs/blob/master/pinning-attacks.md</a><br><br>[2]=
 see &quot;Advances in Bitcoin Contracting : Uniform Policy and Package Rel=
ay&quot; <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev=
/2020-July/018063.html" target=3D"_blank">https://lists.linuxfoundation.org=
/pipermail/bitcoin-dev/2020-July/018063.html</a><br><br>[3] I don&#39;t thi=
nk there is a clear discussion on how SIGHASH_ANYPREVOUT solves pinnings be=
yond those LN meetings logs: <a href=3D"https://gnusha.org/lightning-dev/20=
20-06-08.log" target=3D"_blank">https://gnusha.org/lightning-dev/2020-06-08=
.log</a><br><br></div><div>[4] And I believe such great example has been do=
ne with this recent change proposed for bitcoin core addr-relay policy: <a =
href=3D"https://github.com/bitcoin/bitcoin/pull/21528#issuecomment-80990643=
0" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/21528#issuecom=
ment-809906430</a>, where the PR author did bear the burden of reaching out=
 potentially affected downstream projects.<br></div><div><br>[5] Like one o=
f tx_mutation/sighash_iomap/sponsorship proposal proposed in the thread &qu=
ot;A Stroll through Fee-Bumping Techniques: Input-based vs Child-Pay-for-Pa=
rent&quot; : <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin=
-dev/2021-May/019031.html" target=3D"_blank">https://lists.linuxfoundation.=
org/pipermail/bitcoin-dev/2021-May/019031.html</a><br><br>[6] For a discuss=
ion about fee-bumping issues for L2s extended beyond LN see the analysis of=
 the Revault protocol : <a href=3D"https://arxiv.org/pdf/2102.09392.pdf" ta=
rget=3D"_blank">https://arxiv.org/pdf/2102.09392.pdf</a><br><br>[7] As a WI=
P towards establishing an attacker model, see &quot;Secure Fee-Bumping for =
L2s&quot; <a href=3D"https://bitcoin-problems.github.io/problems/fee-bumpin=
g.html" target=3D"_blank">https://bitcoin-problems.github.io/problems/fee-b=
umping.html</a><br><br>[8] Tx-relay rules as a concern for second-layers ha=
s been raised early on, at least during p2p segwit review <a href=3D"https:=
//github.com/bitcoin/bitcoin/issues/8279" target=3D"_blank">https://github.=
com/bitcoin/bitcoin/issues/8279</a><br></div></div>
</blockquote></div>

--000000000000a48a0005c5147135--