Re: [Lightning-dev] Making unannounced channels harder to probe
Joost Jager writes: >> >> But Joost pointed out that you need to know the node_id of the next node >> though: this isn't quite true, since if the node_id is wrong the spec >> says you should send an `update_fail_malformed_htlc` with failure code >> invalid_onion_hmac, which node N turns into its own failure message. >> Perhaps it should convert it to `unknown_next_peer` instead? This isn't >> a common error on the modern network; I think our onion implementations >> have been rock solid. >> > > Isn't this what I am suggesting here? > https://twitter.com/joostjgr/status/1385150318959341569 Oops, I didn't read the second part of your tweet properly. Sorry: this was right there indeed. Thanks! Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation
Matt Corallo writes: > Somehow I missed this thread, but I did note in a previous meeting - these > issues are great fodder for fuzzing. We’ve had a fuzzer which aggressively > tests for precisely these types of message-non-delivery-and-resending > production desync bugs for several years. When it initially landed it forced > several rewrites of parts of the state machine, but quickly exhausted the bug > fruit (though catches other classes of bugs occasionally as well). The state > machine here is really not that big - while I agree simplifying it where > possible is nice, ripping things out to replace them with fresh code (which > would need similar testing) is probably not the most obvious decrease in > complexity. It's historically had more bugs than anything else in the protocol. We literally found another one in feerate negotiation since the last c-lightning release :( I'd rather not have bugs than try to catch them all. >> I've been revisiting this because it makes things like splicing easier: >> the current draft requires stopping changes while splicing is being >> negotiated, which is not entirely trivial. With the simplified method, >> you don't have to wait at all. > > Hmm, what’s nontrivial about this? How much more complicated is this than > having an alternation to updates and pausing HTLC updates for a cycle or two > while splicing is negotiated (I assume it would still need a similar > requirement, as otherwise you have the same complexity)? We already have a > similar update-stopping process for shutdown, though of course it doesn’t > include restarting. You could propose a splice (or update to anchors, or whatever) any time when it's your turn, as long as you haven't proposed any other updates. That's simple! Instead, *both* sides have to send a splice message to synchronize, and they can only do so once all in-flight changes have cleared. You have to resolve simultaneous splice attempts (we use "highest feerate" tiebreak by node_id), and keep track of this stage while you clear in-flight changes. Here's the subset of requirements from the draft which relate to this: The sender: - MUST NOT send another splice message while a splice is being negotiated. - MUST NOT send a splice message after sending uncommitted changes. - MUST NOT send other channel updates until splice negotiation has completed. The receiver: - MUST respond with a `splice` message of its own if it has not already. - MUST NOT reply with `splice` until all commitment updates are resolved by both peers. - MUST use the higher of the two `funding_feerate_perkw` as the feerate for the splice. - MUST NOT send other channel updates until splice negotiation has completed. Similar requirements exist for other major channel changes. Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Making unannounced channels harder to probe
> > But Joost pointed out that you need to know the node_id of the next node > though: this isn't quite true, since if the node_id is wrong the spec > says you should send an `update_fail_malformed_htlc` with failure code > invalid_onion_hmac, which node N turns into its own failure message. > Perhaps it should convert it to `unknown_next_peer` instead? This isn't > a common error on the modern network; I think our onion implementations > have been rock solid. > Isn't this what I am suggesting here? https://twitter.com/joostjgr/status/1385150318959341569 Joost ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation
> On Apr 20, 2021, at 17:19, Rusty Russell wrote: > > After consideration, I prefer alternation. It fits better with the > existing implementations, and it is more optimal than reflection for > optimized implementations. > > In particular, you have a rule that says you can send updates and > commitment_signed when it's not your turn, and the leader either > responds with a "giving way" message, or ignores your changes and sends > its own. > > A simple implementation *never* sends a commitment_signed until it > receives "giving way" so it doesn't have to deal with orphaned > commitments. A more complex implementation sends opportunistically and > then has to remember that it's committed if it loses the race. Such an > implementation is only slower than the current system if that race > happens. Somehow I missed this thread, but I did note in a previous meeting - these issues are great fodder for fuzzing. We’ve had a fuzzer which aggressively tests for precisely these types of message-non-delivery-and-resending production desync bugs for several years. When it initially landed it forced several rewrites of parts of the state machine, but quickly exhausted the bug fruit (though catches other classes of bugs occasionally as well). The state machine here is really not that big - while I agree simplifying it where possible is nice, ripping things out to replace them with fresh code (which would need similar testing) is probably not the most obvious decrease in complexity. > I've been revisiting this because it makes things like splicing easier: > the current draft requires stopping changes while splicing is being > negotiated, which is not entirely trivial. With the simplified method, > you don't have to wait at all. Hmm, what’s nontrivial about this? How much more complicated is this than having an alternation to updates and pausing HTLC updates for a cycle or two while splicing is negotiated (I assume it would still need a similar requirement, as otherwise you have the same complexity)? We already have a similar update-stopping process for shutdown, though of course it doesn’t include restarting. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Making unannounced channels harder to probe
Hi all, You can currently probe for a channel id attached to node N by sending an HTLC, and seeing whether the error reply comes from the N or the next hop. The real answer is to get back to blinded paths, BTW. But Joost pointed out that you need to know the node_id of the next node though: this isn't quite true, since if the node_id is wrong the spec says you should send an `update_fail_malformed_htlc` with failure code invalid_onion_hmac, which node N turns into its own failure message. Perhaps it should convert it to `unknown_next_peer` instead? This isn't a common error on the modern network; I think our onion implementations have been rock solid. This doesn't help if you've revealed your node id in other ways ofc. i.e. you offer me an invoice, now I probe the rest of the network to find all unannounced channels you have. For that, implementations *could* choose to return `update_fail_malformed_htlc` failure_code=invalid_onion_hmac as above on anything which comes through an unannounced channel but is not a successful payment (or part thereof, i.e. correct payment_hash for outstanding invoice with correct payment_secret field?). Cheers, Rusty. PS. https://twitter.com/cycryptr/status/1384355046381473792 contains exploration. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Increase channel-jamming capital requirements by not counting dust HTLCs
The update_fee message does not, as far as I recall, change the dust limit for outputs in a channel (though I’ve suggested making such a change). > On Apr 23, 2021, at 12:24, Bastien TEINTURIER wrote: > > > Hi Eugene, > > The reason dust HTLCs count for the 483 HTLC limit is because of `update_fee`. > If you don't count them and exceed the 483 HTLC limit, you can't lower the > fee anymore > because some HTLCs that were previously dust won't be dust anymore and you > may end > up with more than 483 HTLC outputs in your commitment, which opens the door > to other > kinds of attacks. > > This is the first issue that comes to mind, but there may be other drawbacks > if we dig into > this enough with an attacker's mindset. > > Bastien > >> Le ven. 23 avr. 2021 à 17:58, Eugene Siegel a écrit : >> I propose a simple mitigation to increase the capital requirement of >> channel-jamming attacks. This would prevent an unsophisticated attacker with >> low capital from jamming a target channel. It seems to me that this is a >> *free* mitigation without any downsides (besides code-writing), so I'd like >> to hear other opinions. >> >> In a commitment transaction, we trim dust HTLC outputs. I believe that the >> reason for the 483 HTLC limit each side has in the spec is to prevent >> commitment tx's from growing unreasonably large, and to ensure they are >> still valid tx's that can be included in a block. If we don't include dust >> HTLCs in this calculation, since they are not on the commitment tx, we still >> allow 483 (x2) non-dust HTLCs to be included on the commitment tx. There >> could be a configurable limit on the number of outstanding dust HTLCs, but >> the point is that it doesn't affect the non-dust throughput of the channel. >> This raises the capital requirement of channel-jamming so that each HTLC >> must be non-dust, rather than spamming 1 sat payments. >> >> Interested in others' thoughts. >> >> Eugene (Crypt-iQ) >> ___ >> Lightning-dev mailing list >> Lightning-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Increase channel-jamming capital requirements by not counting dust HTLCs
Thanks for replying. I was under the impression that long-term update_fee was going to be removed since second-level HTLC txn's can bring their own fees? On Fri, Apr 23, 2021 at 12:24 PM Bastien TEINTURIER wrote: > Hi Eugene, > > The reason dust HTLCs count for the 483 HTLC limit is because of > `update_fee`. > If you don't count them and exceed the 483 HTLC limit, you can't lower the > fee anymore > because some HTLCs that were previously dust won't be dust anymore and you > may end > up with more than 483 HTLC outputs in your commitment, which opens the > door to other > kinds of attacks. > > This is the first issue that comes to mind, but there may be other > drawbacks if we dig into > this enough with an attacker's mindset. > > Bastien > > Le ven. 23 avr. 2021 à 17:58, Eugene Siegel a écrit : > >> I propose a simple mitigation to increase the capital requirement of >> channel-jamming attacks. This would prevent an unsophisticated attacker >> with low capital from jamming a target channel. It seems to me that this >> is a *free* mitigation without any downsides (besides code-writing), so I'd >> like to hear other opinions. >> >> In a commitment transaction, we trim dust HTLC outputs. I believe that >> the reason for the 483 HTLC limit each side has in the spec is to prevent >> commitment tx's from growing unreasonably large, and to ensure they are >> still valid tx's that can be included in a block. If we don't include dust >> HTLCs in this calculation, since they are not on the commitment tx, we >> still allow 483 (x2) non-dust HTLCs to be included on the commitment tx. >> There could be a configurable limit on the number of outstanding dust >> HTLCs, but the point is that it doesn't affect the non-dust throughput of >> the channel. This raises the capital requirement of channel-jamming so >> that each HTLC must be non-dust, rather than spamming 1 sat payments. >> >> Interested in others' thoughts. >> >> Eugene (Crypt-iQ) >> ___ >> Lightning-dev mailing list >> Lightning-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Increase channel-jamming capital requirements by not counting dust HTLCs
Hi Eugene, The reason dust HTLCs count for the 483 HTLC limit is because of `update_fee`. If you don't count them and exceed the 483 HTLC limit, you can't lower the fee anymore because some HTLCs that were previously dust won't be dust anymore and you may end up with more than 483 HTLC outputs in your commitment, which opens the door to other kinds of attacks. This is the first issue that comes to mind, but there may be other drawbacks if we dig into this enough with an attacker's mindset. Bastien Le ven. 23 avr. 2021 à 17:58, Eugene Siegel a écrit : > I propose a simple mitigation to increase the capital requirement of > channel-jamming attacks. This would prevent an unsophisticated attacker > with low capital from jamming a target channel. It seems to me that this > is a *free* mitigation without any downsides (besides code-writing), so I'd > like to hear other opinions. > > In a commitment transaction, we trim dust HTLC outputs. I believe that > the reason for the 483 HTLC limit each side has in the spec is to prevent > commitment tx's from growing unreasonably large, and to ensure they are > still valid tx's that can be included in a block. If we don't include dust > HTLCs in this calculation, since they are not on the commitment tx, we > still allow 483 (x2) non-dust HTLCs to be included on the commitment tx. > There could be a configurable limit on the number of outstanding dust > HTLCs, but the point is that it doesn't affect the non-dust throughput of > the channel. This raises the capital requirement of channel-jamming so > that each HTLC must be non-dust, rather than spamming 1 sat payments. > > Interested in others' thoughts. > > Eugene (Crypt-iQ) > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] L2s Onchain Support IRC Workshop
Great idea, I'll join as well. Thanks for setting this in motion. Le ven. 23 avr. 2021 à 17:39, Antoine Riard a écrit : > Hi Jeremy, > > Yes dates are floating for now. After Bitcoin 2021, sounds a good idea. > > Awesome, I'll be really interested to review again an improved version of > sponsorship. And I'll try to sketch out the sighash_no-input fee-bumping > idea which was floating around last year during pinnings discussions. Yet > another set of trade-offs :) > > Le ven. 23 avr. 2021 à 11:25, Jeremy a écrit : > >> I'd be excited to join. Recommend bumping the date to mid June, if >> that's ok, as many Americans will be at Bitcoin 2021. >> >> I was thinking about reviving the sponsors proposal with a 100 block lock >> on spending a sponsoring tx which would hopefully make less controversial, >> this would be a great place to discuss those tradeoffs. >> >> On Fri, Apr 23, 2021, 8:17 AM Antoine Riard >> wrote: >> >>> Hi, >>> >>> During the lastest years, tx-relay and mempool acceptances rules of the >>> base layer have been sources of major security and operational concerns for >>> Lightning and other Bitcoin second-layers [0]. I think those areas require >>> significant improvements to ease design and deployment of higher Bitcoin >>> layers and I believe this opinion is shared among the L2 dev community. In >>> order to make advancements, it has been discussed a few times in the last >>> months to organize in-person workshops to discuss those issues with the >>> presence of both L1/L2 devs to make exchange fruitful. >>> >>> Unfortunately, I don't think we'll be able to organize such in-person >>> workshops this year (because you know travel is hard those days...) As a >>> substitution, I'm proposing a series of one or more irc meetings. That >>> said, this substitution has the happy benefit to gather far more folks >>> interested by those issues that you can fit in a room. >>> >>> # Scope >>> >>> I would like to propose the following 4 items as topics of discussion. >>> >>> 1) Package relay design or another generic L2 fee-bumping primitive like >>> sponsorship [0]. IMHO, this primitive should at least solve mempools spikes >>> making obsolete propagation of transactions with pre-signed feerate, solve >>> pinning attacks compromising Lightning/multi-party contract protocol >>> safety, offer an usable and stable API to L2 software stack, stay >>> compatible with miner and full-node operators incentives and obviously >>> minimize CPU/memory DoS vectors. >>> >>> 2) Deprecation of opt-in RBF toward full-rbf. Opt-in RBF makes it >>> trivial for an attacker to partition network mempools in divergent subsets >>> and from then launch advanced security or privacy attacks against a >>> Lightning node. Note, it might also be a concern for bandwidth bleeding >>> attacks against L1 nodes. >>> >>> 3) Guidelines about coordinated cross-layers security disclosures. >>> Mitigating a security issue around tx-relay or the mempool in Core might >>> have harmful implications for downstream projects. Ideally, L2 projects >>> maintainers should be ready to upgrade their protocols in emergency in >>> coordination with base layers developers. >>> >>> 4) Guidelines about L2 protocols onchain security design. Currently >>> deployed like Lightning are making a bunch of assumptions on tx-relay and >>> mempool acceptances rules. Those rules are non-normative, non-reliable and >>> lack documentation. Further, they're devoid of tooling to enforce them at >>> runtime [2]. IMHO, it could be preferable to identify a subset of them on >>> which second-layers protocols can do assumptions without encroaching too >>> much on nodes's policy realm or making the base layer development in those >>> areas too cumbersome. >>> >>> I'm aware that some folks are interested in other topics such as >>> extension of Core's mempools package limits or better pricing of RBF >>> replacement. So l propose a 2-week concertation period to submit other >>> topics related to tx-relay or mempools improvements towards L2s before to >>> propose a finalized scope and agenda. >>> >>> # Goals >>> >>> 1) Reaching technical consensus. >>> 2) Reaching technical consensus, before seeking community consensus as >>> it likely has ecosystem-wide implications. >>> 3) Establishing a security incident response policy which can be applied >>> by dev teams in the future. >>> 4) Establishing a philosophy design and associated documentations (BIPs, >>> best practices, ...) >>> >>> # Timeline >>> >>> 2021-04-23: Start of concertation period >>> 2021-05-07: End of concertation period >>> 2021-05-10: Proposition of workshop agenda and schedule >>> late 2021-05/2021-06: IRC meetings >>> >>> As the problem space is savagely wide, I've started a collection of >>> documents to assist this workshop : https://github.com/ariard/L2-zoology >>> Still wip, but I'll have them in a good shape at agenda publication, >>> with reading suggestions and open questions to structure discussions.
[Lightning-dev] Increase channel-jamming capital requirements by not counting dust HTLCs
I propose a simple mitigation to increase the capital requirement of channel-jamming attacks. This would prevent an unsophisticated attacker with low capital from jamming a target channel. It seems to me that this is a *free* mitigation without any downsides (besides code-writing), so I'd like to hear other opinions. In a commitment transaction, we trim dust HTLC outputs. I believe that the reason for the 483 HTLC limit each side has in the spec is to prevent commitment tx's from growing unreasonably large, and to ensure they are still valid tx's that can be included in a block. If we don't include dust HTLCs in this calculation, since they are not on the commitment tx, we still allow 483 (x2) non-dust HTLCs to be included on the commitment tx. There could be a configurable limit on the number of outstanding dust HTLCs, but the point is that it doesn't affect the non-dust throughput of the channel. This raises the capital requirement of channel-jamming so that each HTLC must be non-dust, rather than spamming 1 sat payments. Interested in others' thoughts. Eugene (Crypt-iQ) ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] L2s Onchain Support IRC Workshop
Hi Jeremy, Yes dates are floating for now. After Bitcoin 2021, sounds a good idea. Awesome, I'll be really interested to review again an improved version of sponsorship. And I'll try to sketch out the sighash_no-input fee-bumping idea which was floating around last year during pinnings discussions. Yet another set of trade-offs :) Le ven. 23 avr. 2021 à 11:25, Jeremy a écrit : > I'd be excited to join. Recommend bumping the date to mid June, if that's > ok, as many Americans will be at Bitcoin 2021. > > I was thinking about reviving the sponsors proposal with a 100 block lock > on spending a sponsoring tx which would hopefully make less controversial, > this would be a great place to discuss those tradeoffs. > > On Fri, Apr 23, 2021, 8:17 AM Antoine Riard > wrote: > >> Hi, >> >> During the lastest years, tx-relay and mempool acceptances rules of the >> base layer have been sources of major security and operational concerns for >> Lightning and other Bitcoin second-layers [0]. I think those areas require >> significant improvements to ease design and deployment of higher Bitcoin >> layers and I believe this opinion is shared among the L2 dev community. In >> order to make advancements, it has been discussed a few times in the last >> months to organize in-person workshops to discuss those issues with the >> presence of both L1/L2 devs to make exchange fruitful. >> >> Unfortunately, I don't think we'll be able to organize such in-person >> workshops this year (because you know travel is hard those days...) As a >> substitution, I'm proposing a series of one or more irc meetings. That >> said, this substitution has the happy benefit to gather far more folks >> interested by those issues that you can fit in a room. >> >> # Scope >> >> I would like to propose the following 4 items as topics of discussion. >> >> 1) Package relay design or another generic L2 fee-bumping primitive like >> sponsorship [0]. IMHO, this primitive should at least solve mempools spikes >> making obsolete propagation of transactions with pre-signed feerate, solve >> pinning attacks compromising Lightning/multi-party contract protocol >> safety, offer an usable and stable API to L2 software stack, stay >> compatible with miner and full-node operators incentives and obviously >> minimize CPU/memory DoS vectors. >> >> 2) Deprecation of opt-in RBF toward full-rbf. Opt-in RBF makes it trivial >> for an attacker to partition network mempools in divergent subsets and from >> then launch advanced security or privacy attacks against a Lightning node. >> Note, it might also be a concern for bandwidth bleeding attacks against L1 >> nodes. >> >> 3) Guidelines about coordinated cross-layers security disclosures. >> Mitigating a security issue around tx-relay or the mempool in Core might >> have harmful implications for downstream projects. Ideally, L2 projects >> maintainers should be ready to upgrade their protocols in emergency in >> coordination with base layers developers. >> >> 4) Guidelines about L2 protocols onchain security design. Currently >> deployed like Lightning are making a bunch of assumptions on tx-relay and >> mempool acceptances rules. Those rules are non-normative, non-reliable and >> lack documentation. Further, they're devoid of tooling to enforce them at >> runtime [2]. IMHO, it could be preferable to identify a subset of them on >> which second-layers protocols can do assumptions without encroaching too >> much on nodes's policy realm or making the base layer development in those >> areas too cumbersome. >> >> I'm aware that some folks are interested in other topics such as >> extension of Core's mempools package limits or better pricing of RBF >> replacement. So l propose a 2-week concertation period to submit other >> topics related to tx-relay or mempools improvements towards L2s before to >> propose a finalized scope and agenda. >> >> # Goals >> >> 1) Reaching technical consensus. >> 2) Reaching technical consensus, before seeking community consensus as it >> likely has ecosystem-wide implications. >> 3) Establishing a security incident response policy which can be applied >> by dev teams in the future. >> 4) Establishing a philosophy design and associated documentations (BIPs, >> best practices, ...) >> >> # Timeline >> >> 2021-04-23: Start of concertation period >> 2021-05-07: End of concertation period >> 2021-05-10: Proposition of workshop agenda and schedule >> late 2021-05/2021-06: IRC meetings >> >> As the problem space is savagely wide, I've started a collection of >> documents to assist this workshop : https://github.com/ariard/L2-zoology >> Still wip, but I'll have them in a good shape at agenda publication, with >> reading suggestions and open questions to structure discussions. >> Also working on transaction pinning and mempool partitions attacks >> simulations. >> >> If L2s security/p2p/mempool is your jam, feel free to get involved :) >> >> Cheers, >> Antoine >> >> [0] For e.g see optech section on
Re: [Lightning-dev] L2s Onchain Support IRC Workshop
I'd be excited to join. Recommend bumping the date to mid June, if that's ok, as many Americans will be at Bitcoin 2021. I was thinking about reviving the sponsors proposal with a 100 block lock on spending a sponsoring tx which would hopefully make less controversial, this would be a great place to discuss those tradeoffs. On Fri, Apr 23, 2021, 8:17 AM Antoine Riard wrote: > Hi, > > During the lastest years, tx-relay and mempool acceptances rules of the > base layer have been sources of major security and operational concerns for > Lightning and other Bitcoin second-layers [0]. I think those areas require > significant improvements to ease design and deployment of higher Bitcoin > layers and I believe this opinion is shared among the L2 dev community. In > order to make advancements, it has been discussed a few times in the last > months to organize in-person workshops to discuss those issues with the > presence of both L1/L2 devs to make exchange fruitful. > > Unfortunately, I don't think we'll be able to organize such in-person > workshops this year (because you know travel is hard those days...) As a > substitution, I'm proposing a series of one or more irc meetings. That > said, this substitution has the happy benefit to gather far more folks > interested by those issues that you can fit in a room. > > # Scope > > I would like to propose the following 4 items as topics of discussion. > > 1) Package relay design or another generic L2 fee-bumping primitive like > sponsorship [0]. IMHO, this primitive should at least solve mempools spikes > making obsolete propagation of transactions with pre-signed feerate, solve > pinning attacks compromising Lightning/multi-party contract protocol > safety, offer an usable and stable API to L2 software stack, stay > compatible with miner and full-node operators incentives and obviously > minimize CPU/memory DoS vectors. > > 2) Deprecation of opt-in RBF toward full-rbf. Opt-in RBF makes it trivial > for an attacker to partition network mempools in divergent subsets and from > then launch advanced security or privacy attacks against a Lightning node. > Note, it might also be a concern for bandwidth bleeding attacks against L1 > nodes. > > 3) Guidelines about coordinated cross-layers security disclosures. > Mitigating a security issue around tx-relay or the mempool in Core might > have harmful implications for downstream projects. Ideally, L2 projects > maintainers should be ready to upgrade their protocols in emergency in > coordination with base layers developers. > > 4) Guidelines about L2 protocols onchain security design. Currently > deployed like Lightning are making a bunch of assumptions on tx-relay and > mempool acceptances rules. Those rules are non-normative, non-reliable and > lack documentation. Further, they're devoid of tooling to enforce them at > runtime [2]. IMHO, it could be preferable to identify a subset of them on > which second-layers protocols can do assumptions without encroaching too > much on nodes's policy realm or making the base layer development in those > areas too cumbersome. > > I'm aware that some folks are interested in other topics such as extension > of Core's mempools package limits or better pricing of RBF replacement. So > l propose a 2-week concertation period to submit other topics related to > tx-relay or mempools improvements towards L2s before to propose a finalized > scope and agenda. > > # Goals > > 1) Reaching technical consensus. > 2) Reaching technical consensus, before seeking community consensus as it > likely has ecosystem-wide implications. > 3) Establishing a security incident response policy which can be applied > by dev teams in the future. > 4) Establishing a philosophy design and associated documentations (BIPs, > best practices, ...) > > # Timeline > > 2021-04-23: Start of concertation period > 2021-05-07: End of concertation period > 2021-05-10: Proposition of workshop agenda and schedule > late 2021-05/2021-06: IRC meetings > > As the problem space is savagely wide, I've started a collection of > documents to assist this workshop : https://github.com/ariard/L2-zoology > Still wip, but I'll have them in a good shape at agenda publication, with > reading suggestions and open questions to structure discussions. > Also working on transaction pinning and mempool partitions attacks > simulations. > > If L2s security/p2p/mempool is your jam, feel free to get involved :) > > Cheers, > Antoine > > [0] For e.g see optech section on transaction pinning attacks : > https://bitcoinops.org/en/topics/transaction-pinning/ > [1] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html > [2] Lack of reference tooling make it easier to have bug slip in like > https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002858.html > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org >
[Lightning-dev] L2s Onchain Support IRC Workshop
Hi, During the lastest years, tx-relay and mempool acceptances rules of the base layer have been sources of major security and operational concerns for Lightning and other Bitcoin second-layers [0]. I think those areas require significant improvements to ease design and deployment of higher Bitcoin layers and I believe this opinion is shared among the L2 dev community. In order to make advancements, it has been discussed a few times in the last months to organize in-person workshops to discuss those issues with the presence of both L1/L2 devs to make exchange fruitful. Unfortunately, I don't think we'll be able to organize such in-person workshops this year (because you know travel is hard those days...) As a substitution, I'm proposing a series of one or more irc meetings. That said, this substitution has the happy benefit to gather far more folks interested by those issues that you can fit in a room. # Scope I would like to propose the following 4 items as topics of discussion. 1) Package relay design or another generic L2 fee-bumping primitive like sponsorship [0]. IMHO, this primitive should at least solve mempools spikes making obsolete propagation of transactions with pre-signed feerate, solve pinning attacks compromising Lightning/multi-party contract protocol safety, offer an usable and stable API to L2 software stack, stay compatible with miner and full-node operators incentives and obviously minimize CPU/memory DoS vectors. 2) Deprecation of opt-in RBF toward full-rbf. Opt-in RBF makes it trivial for an attacker to partition network mempools in divergent subsets and from then launch advanced security or privacy attacks against a Lightning node. Note, it might also be a concern for bandwidth bleeding attacks against L1 nodes. 3) Guidelines about coordinated cross-layers security disclosures. Mitigating a security issue around tx-relay or the mempool in Core might have harmful implications for downstream projects. Ideally, L2 projects maintainers should be ready to upgrade their protocols in emergency in coordination with base layers developers. 4) Guidelines about L2 protocols onchain security design. Currently deployed like Lightning are making a bunch of assumptions on tx-relay and mempool acceptances rules. Those rules are non-normative, non-reliable and lack documentation. Further, they're devoid of tooling to enforce them at runtime [2]. IMHO, it could be preferable to identify a subset of them on which second-layers protocols can do assumptions without encroaching too much on nodes's policy realm or making the base layer development in those areas too cumbersome. I'm aware that some folks are interested in other topics such as extension of Core's mempools package limits or better pricing of RBF replacement. So l propose a 2-week concertation period to submit other topics related to tx-relay or mempools improvements towards L2s before to propose a finalized scope and agenda. # Goals 1) Reaching technical consensus. 2) Reaching technical consensus, before seeking community consensus as it likely has ecosystem-wide implications. 3) Establishing a security incident response policy which can be applied by dev teams in the future. 4) Establishing a philosophy design and associated documentations (BIPs, best practices, ...) # Timeline 2021-04-23: Start of concertation period 2021-05-07: End of concertation period 2021-05-10: Proposition of workshop agenda and schedule late 2021-05/2021-06: IRC meetings As the problem space is savagely wide, I've started a collection of documents to assist this workshop : https://github.com/ariard/L2-zoology Still wip, but I'll have them in a good shape at agenda publication, with reading suggestions and open questions to structure discussions. Also working on transaction pinning and mempool partitions attacks simulations. If L2s security/p2p/mempool is your jam, feel free to get involved :) Cheers, Antoine [0] For e.g see optech section on transaction pinning attacks : https://bitcoinops.org/en/topics/transaction-pinning/ [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html [2] Lack of reference tooling make it easier to have bug slip in like https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002858.html ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
