From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Date: Fri, 18 Jun 2021 18:11:38 -0400 Message-ID: To: Bitcoin Protocol Discussion , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
Hi,

It'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

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.

1= ) Lightning Safety Holes : Pre-Signed Feerate and Tx-Pinning (to skip if yo= u'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 ti= me-sensitive transactions is laid out clearly in Matt Corallo's "C= PFP Carve-Out Fee-Prediction Issues in Contracting Applications (eg Lightni= ng)" [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.=

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 "fractional-reserve" backed anchor cha= nnels, 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 Bast= ien Teinturier's "Pinning Attacks" [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'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's `update= _fee` policy, LN implementation'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't fit well.

Si= de-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. 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.

2) Solving the Pre-Signed Feerate proble= m : Package-Relay or SIGHASH_ANYPREVOUT

For Lightning, either packag= e-relay or SIGHASH_ANYPREVOUT should be able to solve the pre-signed feerat= e issue [3]

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.

I did express the contrary, public o= pinion a while back [4]. That said, I start to agree it'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]

On this rational, I now share the opini= on 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 of= f-chain coins relying on the weaker assumptions offered by bitcoin core'= ;s tx-relay/mempool acceptance rules, and far harder to replicate and disse= minate across the ecosystem.

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

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*=

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 "patch".

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's worthy the engineering resources cost.= From-my-completely-biased-LN-dev viewpoint :p

In the best-case scen= ario, we'll activate SIGHASH_ANYPREVOUT and better fee-bumping primitiv= es 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 re= placement of our orphan logic.

3) Solving Tx-Pinnings : Hardening th= e 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 secur= ity vulnerabilities for Lightning and a research concern for L2s still in t= he early-phase of deployment [6].

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.

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 a= dvanced Bitcoin protocols (e.g OP_CTV congestion tree,=C2=A0 CoinPool, inte= ractive 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,=C2=A0 L2s should be well-aware the product is shipped with a guarant= ee limitation :p

4) Considerations on Package-Relay Design

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

One open design question for= the "higher half" 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's a question I hope we= 9;ll gather feedback during next Thursday'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'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 im= plementation reserving itself the right to deprecate them, maybe with a len= gthy-warning period ?

Beyond that, I believe there is another remain= ing interdependency between "the lower half" design and L2s behav= iors, namely bandwidth waste in case of a high-frequency of package redunda= ncy. Let's say if a package is composed of {A, B}, and the package broa= dcaster fee-bump, triggering the transformation to {A, B'}, 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.

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's bandwidth.<= 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 ?

= 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 conc= ern 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= 9;t be the first time [8]

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.

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= .

Though ultimately, this question of p2p design belongs to the bitc= oin core dev process.

# Deployment timeline

So what I believe= as a rough deployment timeline.

* "package-relay" in bitc= oin 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&= #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

* 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 (o= ne of tx mutation/sigash_iomap/sponsorship proposals) softfork in the comin= g decade, friendly uplift of the L2 ecosystem

Glad to answer any unc= larity or uncorrectness of mine :)

Cheers,
Antoine,

[0] se= e https://lists.linuxfoundation.org/pi= permail/bitcoin-dev/2018-November/016518.html

[1] "The Coup= ling Principle states that as things get larger, they often exhibit increas= ed interdependence between components".

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

[2] see "Advances in Bitcoin Contracting : Uniform= Policy and Package Relay" https://li= sts.linuxfoundation.org/pipermail/bitcoin-dev/2020-July/018063.html
=
[3] I don't think there is a clear discussion on how SIGHASH_ANYPRE= VOUT solves pinnings beyond those LN meetings logs: https://gnusha.org/l= ightning-dev/2020-06-08.log

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

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

[6] For a di= scussion about fee-bumping issues for L2s extended beyond LN see the analys= is 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-laye= rs has been raised early on, at least during p2p segwit review https://gi= thub.com/bitcoin/bitcoin/issues/8279
--0000000000004452ba05c5119cbc--