{"type":"rich","version":"1.0","author_name":"npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwta","author_url":"https://nostr.ae/npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwta","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-06-21\n📝 Original message:\nHi ZmnSCPxj,\n\nMy understanding is that you can use the CTV deferral to also get\nindependent HTLC relative timelocks start points per output. This would\nhelp with this sort of issue right?\n\nAnd you're correct that there's overhead of indirection, but it's not super\nlarge (minimally complicated something like an extra 100 bytes per output,\nif you were to have a flat array where each entry is a CTV output so that\neach out gets its own clock).\n\nEssentially something like this:\n\nChan\n     |\n     ---------------------------------------------\n     |           |             |             |            |\nCTV(A) CTV(B) CTV(C) CTV(D)      (Optional CPFP Anchor?)\n     |           |             |             |\n1 block    1 block   1 block   1 block\n     |           |             |             |\n    A          B           C            D\n\nWhere A B C and D are all HTLCs.\n\nNow because of the one-hop indirection, A B C and D can all expand\nindependently. It's also possible for the Channel Operator to do something\nlike:\n\nChan\n     |\n     ---------------------------------------------\n     |           |             |             |            |\nCTV(A) CTV(B) CTV(C) CTV(D)      (Optional CPFP Anchor?)\n     |           |             |             |\n1 block    1 block   1 block   10 blocks\n     |           |             |             |\n    A          B           C            D\n\nTo make D have a further out resolution time to prevent the\nsimultaneous-ness issue (trees or a linear-chain rather than total fan-out\ncan also be used but I think it's a bit more confusing for a basic\nexample). The benefit of trees is that I can do something like:\n\n\nChan\n     |\n     --------------------------------------------------------\n     |           |             |             |                          |\nCTV(A) CTV(B) CTV(C) CTV(400 HTLC)      (Optional CPFP Anchor?)\n     |           |             |             |                |\n1 block    1 block   1 block   10 blocks  (Optional CPFP Anchor?)\n     |           |             |              |\n     |           |             |             / ....\\\n    A          B           C            | ..... |\n\nWhich makes it so that the low-value new HTLCs can be deprioritized fee\nwise. So that the attack, which occurs during a fee spike, doesn't end up\n*requiring* substantial fees to be added to the channel to support a burst\nof HTLCS.\n\n--\n@JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\u003chttps://twitter.com/JeremyRubin\u003e\n\n\nOn Sat, Jun 20, 2020 at 8:34 PM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\n\u003e Good morning Jeremy,\n\u003e\n\u003e \u003e I am not steeped enough in Lightning Protocol issues to get the full\n\u003e design space, but I'm fairly certain BIP-119 Congestion Control trees would\n\u003e help with this issue.\n\u003e \u003e\n\u003e \u003e You can bucket a tree by doing a histogram of HTLC size, so that all\n\u003e small HTLCs live in a common CTV subtree and don't interfere with higher\n\u003e value HTLCs. You can also play with sequencing to prevent those HTLCs from\n\u003e getting longchains in the mempool until they're above a certain value.\n\u003e\n\u003e If the attacker stops responding, then all HTLC rules need to be published\n\u003e onchain for enforcement of the HTLC rules.\n\u003e And that publication onchain is the problem: every HTLC published requires\n\u003e onchain space, which must be paid for.\n\u003e\n\u003e The most compact way to expose the HTLCs is as a flat array, i.e. outputs\n\u003e of a single transaction.\n\u003e Every tree structure is going to take up more space than a flat array.\n\u003e\n\u003e What CTV buys is to be able to defer *when* you reveal scripts, possibly\n\u003e to a later time when blockchain space is cheaper.\n\u003e But in case the victim owns the timelock branch of an outgoing HTLC, it is\n\u003e unsafe for the victim to defer: it has to enforce the locktime soon or it\n\u003e could end up losing both incoming and outgoing HTLC amounts.\n\u003e And to enforce the locktime it has to publish the HTLC.\n\u003e\n\u003e Now of course with CTV you could publish only the HTLC you have to enforce\n\u003e *now*, and keep the rest in an CTV output.\n\u003e The attacker can counter this by pushing 483 HTLCs with the same timelock\n\u003e at the victim, so that the victim has to publish all HTLCs simultaneously.\n\u003e And a flat array of outputs is cheaper than a tree.\n\u003e\n\u003e What *can* be done would be to bin by timelock rather than amount; tree\n\u003e leaves are a transaction that exposes all HTLCs with a particular timelock\n\u003e as a flat array of outputs, but different timelocks go to different tree\n\u003e branches.\n\u003e But the attacker can still do the same-timelock trick, and the tree\n\u003e structure is likely to take up more space in the end than just a non-treed\n\u003e flat array of outputs.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e\n\u003e \u003e --\n\u003e \u003e @JeremyRubin\n\u003e \u003e\n\u003e \u003e On Thu, Jun 18, 2020 at 1:41 AM Antoine Riard \u003cantoine.riard at gmail.com\u003e\n\u003e wrote:\n\u003e \u003e\n\u003e \u003e \u003e Hi Rene,\n\u003e \u003e \u003e Thanks for disclosing this vulnerability,\n\u003e \u003e \u003e\n\u003e \u003e \u003e I think this blackmail scenario holds but sadly there is a lower\n\u003e scenario.\n\u003e \u003e \u003e\n\u003e \u003e \u003e Both \"Flood \u0026 Loot\" and your blackmail attack rely on `update_fee`\n\u003e mechanism and unbounded commitment transaction size inflation. Though the\n\u003e first to provoke block congestion and yours to lockdown in-flight fees as\n\u003e funds hostage situation.\n\u003e \u003e \u003e\n\u003e \u003e \u003e \u003e 1. The current solution is to just not use up the max value of\n\u003e htlc's. Eclaire and c-lightning by default only use up to 30 htlcs.\n\u003e \u003e \u003e\n\u003e \u003e \u003e As of today, yes I would recommend capping commitment size both for\n\u003e ensuring competitive propagation/block selection and limiting HTLC exposure.\n\u003e \u003e \u003e\n\u003e \u003e \u003e \u003e 2. Probably the best fix (not sure if I understand the consequences\n\u003e correctly) is coming from this PR to bitcoin core (c.f.\n\u003e https://github.com/bitcoin/bitcoin/pull/15681 by @TheBlueMatt . If I get\n\u003e it correctly with that we could always have low fees and ask the person who\n\u003e want to claim their outputs to pay fees. This excludes overpayment and\n\u003e could happen at a later stage when fees are not spiked. Still the victim\n\u003e who offered the htlcs would have to spend those outputs at some time.\n\u003e \u003e \u003e\n\u003e \u003e \u003e It's a bit more complex, carve-out output, even combined with anchor\n\u003e output support on the LN-side won't protect against different flavors of\n\u003e pinning. I invite you to go through logs of past 2 LN dev meetings.\n\u003e \u003e \u003e\n\u003e \u003e \u003e \u003e 3. Don't overpay fees in commitment transactions. We can't foresee\n\u003e the future anyway\n\u003e \u003e \u003e\n\u003e \u003e \u003e Once 2. is well-addressed we may deprecate `update_fee`.\n\u003e \u003e \u003e\n\u003e \u003e \u003e \u003e 4. Don't add htlcs for which the on chain fee is higher than the\n\u003e HTLCs value (like we do with sub dust amounts and sub satoshi amounts. This\n\u003e would at least make the attack expensive as the attacker would have to bind\n\u003e a lot of liquidity.\n\u003e \u003e \u003e\n\u003e \u003e \u003e Ideally we want dust_limit to be dynamic, dust cap should be based on\n\u003e HTLC economic value, feerate of its output, feerate of HTLC-transaction,\n\u003e feerate estimation of any CPFP to bump it. I think that's kind of worthy to\n\u003e do once we solved 3. and 4\n\u003e \u003e \u003e\n\u003e \u003e \u003e \u003e 5. Somehow be able to aggregate htlc's. In a world where we use\n\u003e payment points instead of preimages we might be able to do so. It would be\n\u003e really cool if separate HTLC's could be combined to 1 single output. I\n\u003e played around a little bit but I have not come up with a scheme that is\n\u003e more compact in all cases. Thus I just threw in the idea.\n\u003e \u003e \u003e\n\u003e \u003e \u003e Yes we may encode all HTLC in some Taproot tree in the future. There\n\u003e are some wrinkles but for a high-level theoretical construction see my post\n\u003e on CoinPool.\n\u003e \u003e \u003e\n\u003e \u003e \u003e \u003e 6. Split onchain fees differently (now the attacker would also lose\n\u003e fees by conducting this attack) - No I don't want to start yet another fee\n\u003e bikeshadding debate. (In particular I believe that a different split of\n\u003e fees might make the Flood \u0026 Loot attack economically more viable which\n\u003e relies on the same principle)\n\u003e \u003e \u003e\n\u003e \u003e \u003e Likely a bit more of fee bikeshedding is something we have to do to\n\u003e make LN secure... Switching fee from pre-committed ones to a single-party,\n\u003e dynamic one.\n\u003e \u003e \u003e\n\u003e \u003e \u003e \u003e Independently I think we should have a hint in our readme file about\n\u003e where and how people can disclose attacks and vulnerabilities.\n\u003e Implementations have this but the BOLTs do not.\n\u003e \u003e \u003e\n\u003e \u003e \u003e I 100% agree, that's exactly\n\u003e https://github.com/lightningnetwork/lightning-rfc/pull/772, waiting for\n\u003e your feedback :)\n\u003e \u003e \u003e\n\u003e \u003e \u003e Cheers,\n\u003e \u003e \u003e\n\u003e \u003e \u003e Antoine\n\u003e \u003e \u003e\n\u003e \u003e \u003e Le mer. 17 juin 2020 à 09:41, ZmnSCPxj via Lightning-dev \u003c\n\u003e lightning-dev at lists.linuxfoundation.org\u003e a écrit :\n\u003e \u003e \u003e\n\u003e \u003e \u003e \u003e Good morning all,\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e \u003e Fee futures could help against this.\n\u003e \u003e \u003e \u003e \u003e I remember writing about this some time ago but cannot find where\n\u003e (not sure if it was in lightning-dev or bitcoin-dev).\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e `harding` found it:\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017601.html\n\u003e \u003e \u003e \u003e\n\u003e \u003e \u003e \u003e Regards,\n\u003e \u003e \u003e \u003e ZmnSCPxj\n\u003e \u003e \u003e \u003e _______________________________________________\n\u003e \u003e \u003e \u003e Lightning-dev mailing list\n\u003e \u003e \u003e \u003e Lightning-dev at lists.linuxfoundation.org\n\u003e \u003e \u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e \u003e \u003e\n\u003e \u003e \u003e _______________________________________________\n\u003e \u003e \u003e Lightning-dev mailing list\n\u003e \u003e \u003e Lightning-dev at lists.linuxfoundation.org\n\u003e \u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200621/8e0db1ae/attachment-0001.html\u003e"}