rich1.0npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwtahttps://nostr.ae/npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwtanjumphttps://nostr.ae📅 Original date posted:2020-06-20 📝 Original message: I am not steeped enough in Lightning Protocol issues to get the full design space, but I'm fairly certain BIP-119 Congestion Control trees would help with this issue. You can bucket a tree by doing a histogram of HTLC size, so that all small HTLCs live in a common CTV subtree and don't interfere with higher value HTLCs. You can also play with sequencing to prevent those HTLCs from getting longchains in the mempool until they're above a certain value. -- @JeremyRubin <https://twitter.com/JeremyRubin> <https://twitter.com/JeremyRubin> On Thu, Jun 18, 2020 at 1:41 AM Antoine Riard <antoine.riard at gmail.com> wrote: > Hi Rene, > > Thanks for disclosing this vulnerability, > > I think this blackmail scenario holds but sadly there is a lower scenario. > > Both "Flood & Loot" and your blackmail attack rely on `update_fee` > mechanism and unbounded commitment transaction size inflation. Though the > first to provoke block congestion and yours to lockdown in-flight fees as > funds hostage situation. > > > 1. The current solution is to just not use up the max value of > htlc's. Eclaire and c-lightning by default only use up to 30 htlcs. > > As of today, yes I would recommend capping commitment size both for > ensuring competitive propagation/block selection and limiting HTLC exposure. > > > 2. Probably the best fix (not sure if I understand the consequences > correctly) is coming from this PR to bitcoin core (c.f. > https://github.com/bitcoin/bitcoin/pull/15681 by @TheBlueMatt . If I get > it correctly with that we could always have low fees and ask the person who > want to claim their outputs to pay fees. This excludes overpayment and > could happen at a later stage when fees are not spiked. Still the victim > who offered the htlcs would have to spend those outputs at some time. > > It's a bit more complex, carve-out output, even combined with anchor > output support on the LN-side won't protect against different flavors of > pinning. I invite you to go through logs of past 2 LN dev meetings. > > > 3. Don't overpay fees in commitment transactions. We can't foresee the > future anyway > > Once 2. is well-addressed we may deprecate `update_fee`. > > > 4. Don't add htlcs for which the on chain fee is higher than the HTLCs > value (like we do with sub dust amounts and sub satoshi amounts. This would > at least make the attack expensive as the attacker would have to bind a lot > of liquidity. > > Ideally we want dust_limit to be dynamic, dust cap should be based on HTLC > economic value, feerate of its output, feerate of HTLC-transaction, feerate > estimation of any CPFP to bump it. I think that's kind of worthy to do once > we solved 3. and 4 > > > 5. Somehow be able to aggregate htlc's. In a world where we use payment > points instead of preimages we might be able to do so. It would be really > cool if separate HTLC's could be combined to 1 single output. I played > around a little bit but I have not come up with a scheme that is more > compact in all cases. Thus I just threw in the idea. > > Yes we may encode all HTLC in some Taproot tree in the future. There are > some wrinkles but for a high-level theoretical construction see my post on > CoinPool. > > > 6. Split onchain fees differently (now the attacker would also lose fees > by conducting this attack) - No I don't want to start yet another fee > bikeshadding debate. (In particular I believe that a different split of > fees might make the Flood & Loot attack economically more viable which > relies on the same principle) > > Likely a bit more of fee bikeshedding is something we have to do to make > LN secure... Switching fee from pre-committed ones to a single-party, > dynamic one. > > > Independently I think we should have a hint in our readme file about > where and how people can disclose attacks and vulnerabilities. > Implementations have this but the BOLTs do not. > > I 100% agree, that's exactly > https://github.com/lightningnetwork/lightning-rfc/pull/772, waiting for > your feedback :) > > Cheers, > > Antoine > > Le mer. 17 juin 2020 à 09:41, ZmnSCPxj via Lightning-dev < > lightning-dev at lists.linuxfoundation.org> a écrit : > >> >> Good morning all, >> >> > >> > Fee futures could help against this. >> > I remember writing about this some time ago but cannot find where (not >> sure if it was in lightning-dev or bitcoin-dev). >> >> `harding` found it: >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017601.html >> >> Regards, >> ZmnSCPxj >> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200620/3c0b6b52/attachment.html>