Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id C3210C000B; Sat, 19 Jun 2021 01:34:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 9CDC9842BD; Sat, 19 Jun 2021 01:34:44 +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 fOuLmKfErDGi; Sat, 19 Jun 2021 01:34:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) by smtp1.osuosl.org (Postfix) with ESMTPS id 5256882C75; Sat, 19 Jun 2021 01:34:42 +0000 (UTC) Received: by mail-wr1-x42c.google.com with SMTP id o3so12675230wri.8; Fri, 18 Jun 2021 18:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=3WBqKoVHy52fhE16nmli/gfE/bzgngPEBC/G6dzVSO4=; b=TUxHx48tJq67PMKvQBl/z7Cn4ugwyrWGW6tlvlRwiuzZTqL3JfyHt1hLB9mvqt5nZQ Qak7hXazG+s534iMDgOu7RM/DlHJ0vqOa6zGBY6QU2tQb3/M7AT8KpXQ8h4jn7SfYdWB 2uVF+x9y23TXSGbnkZBwqeoVBmvX2wNqUZKiqYmaIN/I0KWA3Hc8oB/kLCK/l1HfAxbW 1J+pTg0bDm8xqlpCuSvTAiN5oU2QFt9DbbRr4k3INU/uWesSot8U+LHP4UNpCbzplJKj ACa2nCbNEcZK+lEf1CRl92OCWxBRRS+LRXU8VuYAHRrs4fj8SeKiN+7wMAjYgtTSB3AD HuQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=3WBqKoVHy52fhE16nmli/gfE/bzgngPEBC/G6dzVSO4=; b=j5v25bsq2OdkuOcF7s3lR7scAPG+agXpT6VszegnvNqEVqc7eHk+fE63Za+NE2jIYU aMyWQ273bMVs2Kvug7ZyEeuhD0PYfwANROIauNo+s+KVvjVevtwPKSF92eHVORwF3Ts3 o50uB+3VtyGzUNUDZ6sKfKWYWcmDbgxj+EUKAmL3vIqvyOeiJfFLYvIvpbPgeAo5ijFO 2qMoqRclteN/x0UZaMYzilOqIfkOvJNQMGMY0aixhYH1SmouEpmR/5ZQ9DgTXF6cpuOu VNi7sHjEZv6Q4KlhueeGBJnNm4esDxn3ZQ0cnflGnTaC1XSWRpM08sAfHTl8FqdlqqDy 5gpg== X-Gm-Message-State: AOAM5308cShuf/kBh/+hnQN2etl21TjSqU6SeQY1DFlMPoSSdvseO92U UKZ0zKHsFgraHbe8CDVol4A9yVDRLEKlGTSntWYWtVzb2NU= X-Google-Smtp-Source: ABdhPJwsXzgPXrucsFL6AsCILbopKaCXMHg55tffwzryjZq9T2Comr0aGrfJlLMFVhqJYPN/hmwkrfYDP95NgXFH52M= X-Received: by 2002:a5d:40c7:: with SMTP id b7mr5836184wrq.224.1624066480178; Fri, 18 Jun 2021 18:34:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Fri, 18 Jun 2021 21:34:28 -0400 Message-ID: To: Bitcoin Protocol Discussion , "lightning-dev\\\\@lists.linuxfoundation.org" Content-Type: multipart/alternative; boundary="000000000000a48a0005c5147135" X-Mailman-Approved-At: Sat, 19 Jun 2021 02:23:32 +0000 Subject: Re: [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: Sat, 19 Jun 2021 01:34:44 -0000 --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 = 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
> That's a question I hope we'll gath= er feedback during next Thursday's transaction relay workshops.

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



Le=C2=A0ven. 18= juin 2021 =C3=A0=C2=A018:11, Antoine Riard <antoine.riard@gmail.com> a =C3=A9crit=C2=A0:
<= div>Hi,

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

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.

1) Lightning Safety Hole= s : Pre-Signed Feerate and Tx-Pinning (to skip if you're a LN dev)
<= br>As of today, Lightning is suffering from 2 safety holes w.r.t to base-la= yer interactions, widely discussed among ln devs.

The first one, the= pre-signed feerate issue with future broadcasted time-sensitive transactio= ns is laid out clearly in Matt Corallo's "CPFP Carve-Out Fee-Predi= ction Issues in Contracting Applications (eg Lightning)" [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.

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 "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, m= alicious transaction pinnings, is documented in Bastien Teinturier's &q= uot;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 ma= trix (channel types, LN implementation's `update_fee` policy, LN implem= entation'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't fit well.

Side-note, as a LN operat= or, if you're worried about those security risks, you can bump your `cl= tv_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 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.

2) Solving the Pre-Signed Feerate problem : Package-Relay or SI= GHASH_ANYPREVOUT

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

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.

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 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]

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 o= n the weaker assumptions offered by bitcoin core's tx-relay/mempool acc= eptance rules, and far harder to replicate and disseminate across the ecosy= stem.

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

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*

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

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

In the best-case scenario, we'll activat= e SIGHASH_ANYPREVOUT and better fee-bumping primitives softforks [5] slowly= strip off the "L2 fee-bumping primitive" semantic from "pac= kage-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-Re= lay Jammings attacks

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

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.

I believe the first part of such a revamp could hopefully land s= omehow next year. Though, IMHO, in the years to come, we'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, ..= .)

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
4) Considerations on Package-Relay Design

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

One open design question for the "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's a question I hope we'll gather feedback du= ring 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 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'= ;t speak C++ :)

One could imagine those mempool standards= as "perishable" 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 ?
Beyond that, I believe there is another remaining interdependency bet= ween "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, trigg= ering the transformation to {A, B'}, 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.

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

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 ?

Lastly, there is a cons= ideration to have around anti-DoS measures we'll have to deploy for pac= kage-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 a= gainst 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 pa= ckage-relay v.0, like if we upgrade some components of it such as package f= ormat or package-announcement scheme.

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.

Though ultimat= ely, 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 integra= te/exercise/provide feedback on package API

* "mempool hardenin= g" in bitcoin core, early 0.26 or 0.27, a Core'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

* 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

* "optimized= /multi-party fee-bumping primitive" softfork (one of tx mutation/sigas= h_iomap/sponsorship proposals) softfork in the coming decade, friendly upli= ft of the L2 ecosystem

Glad to answer any unclarity or uncorrectness= of mine :)

Cheers,
Antoine,

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

[1] "The Coupling Principle states t= hat as things get larger, they often exhibit increased interdependence betw= een components".

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

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

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

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

[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" : https://lists.linuxfoundation.= org/pipermail/bitcoin-dev/2021-May/019031.html

[6] For a discuss= ion 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 WI= P towards establishing an attacker model, see "Secure Fee-Bumping for = L2s" https://bitcoin-problems.github.io/problems/fee-b= umping.html

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