Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2021-06-18 📝 Original message: > That's a question I ...
📅 Original date posted:2021-06-18
📝 Original message:
> 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 à 18:11, Antoine Riard <antoine.riard at gmail.com> a
écrit :
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210618/c61cd0b8/attachment-0001.html>;
📝 Original message:
> 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 à 18:11, Antoine Riard <antoine.riard at gmail.com> a
écrit :
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210618/c61cd0b8/attachment-0001.html>;