{"type":"rich","version":"1.0","author_name":"npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","author_url":"https://nostr.ae/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-06-18\n📝 Original message:\nHi Rene,\n\nThanks for disclosing this vulnerability,\n\nI think this blackmail scenario holds but sadly there is a lower scenario.\n\nBoth \"Flood \u0026 Loot\" and your blackmail attack rely on `update_fee`\nmechanism and unbounded commitment transaction size inflation. Though the\nfirst to provoke block congestion and yours to lockdown in-flight fees as\nfunds hostage situation.\n\n\u003e 1. The current solution is to just not use up the max value of\nhtlc's. Eclaire and c-lightning by default only use up to 30 htlcs.\n\nAs of today, yes I would recommend capping commitment size both for\nensuring competitive propagation/block selection and limiting HTLC exposure.\n\n\u003e 2. Probably the best fix (not sure if I understand the consequences\ncorrectly) is coming from this PR to bitcoin core (c.f.\nhttps://github.com/bitcoin/bitcoin/pull/15681 by @TheBlueMatt . If I get it\ncorrectly with that we could always have low fees and ask the person who\nwant to claim their outputs to pay fees. This excludes overpayment and\ncould happen at a later stage when fees are not spiked. Still the victim\nwho offered the htlcs would have to spend those outputs at some time.\n\nIt's a bit more complex, carve-out output, even combined with anchor output\nsupport on the LN-side won't protect against different flavors of pinning.\nI invite you to go through logs of past 2 LN dev meetings.\n\n\u003e 3. Don't overpay fees in commitment transactions. We can't foresee the\nfuture anyway\n\nOnce 2. is well-addressed we may deprecate `update_fee`.\n\n\u003e 4. Don't add htlcs for which the on chain fee is higher than the HTLCs\nvalue (like we do with sub dust amounts and sub satoshi amounts. This would\nat least make the attack expensive as the attacker would have to bind a lot\nof liquidity.\n\nIdeally we want dust_limit to be dynamic, dust cap should be based on HTLC\neconomic value, feerate of its output, feerate of HTLC-transaction, feerate\nestimation of any CPFP to bump it. I think that's kind of worthy to do once\nwe solved 3. and 4\n\n\u003e 5. Somehow be able to aggregate htlc's. In a world where we use payment\npoints instead of preimages we might be able to do so. It would be really\ncool if separate HTLC's could be combined to 1 single output. I played\naround a little bit but I have not come up with a scheme that is more\ncompact in all cases. Thus I just threw in the idea.\n\nYes we may encode all HTLC in some Taproot tree in the future. There are\nsome wrinkles but for a high-level theoretical construction see my post on\nCoinPool.\n\n\u003e 6. Split onchain fees differently (now the attacker would also lose fees\nby conducting this attack) - No I don't want to start yet another fee\nbikeshadding debate. (In particular I believe that a different split of\nfees might make the Flood \u0026 Loot attack economically more viable which\nrelies on the same principle)\n\nLikely a bit more of fee bikeshedding is something we have to do to make LN\nsecure... Switching fee from pre-committed ones to a single-party, dynamic\none.\n\n\u003e Independently I think we should have a hint in our readme file about\nwhere and how people can disclose attacks and vulnerabilities.\nImplementations have this but the BOLTs do not.\n\nI 100% agree, that's exactly\nhttps://github.com/lightningnetwork/lightning-rfc/pull/772, waiting for\nyour feedback :)\n\nCheers,\n\nAntoine\n\nLe mer. 17 juin 2020 à 09:41, ZmnSCPxj via Lightning-dev \u003c\nlightning-dev at lists.linuxfoundation.org\u003e a écrit :\n\n\u003e\n\u003e Good morning all,\n\u003e\n\u003e \u003e\n\u003e \u003e Fee futures could help against this.\n\u003e \u003e I remember writing about this some time ago but cannot find where (not\n\u003e sure if it was in lightning-dev or bitcoin-dev).\n\u003e\n\u003e `harding` found it:\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017601.html\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200618/4505fed3/attachment.html\u003e"}