Yes -- to be clear, most of the feature-wise benefits of CTV for Lightning are only in the initial channel setup phase, lessening interactivity requirements.
Everything else can be emulated via multisig layers, but that can add substantial latency in doing either 2pECDSA for each layer or on chain & storage overhead in the signature space. CTV helps here because it can be both deterministic & compact, but is not adding a new feature to already interactive protocols. This does end up helping in terms of the feasibility of some of the HTLC indirection tree techniques though :). -- @JeremyRubin <https://twitter.com/JeremyRubin> <https://twitter.com/JeremyRubin> On Sun, Jun 21, 2020 at 6:20 PM Olaoluwa Osuntokun <laol...@gmail.com> wrote: > Hi Jeremy, > > The up-front costs can be further mitigated even without something like CTV > (which makes things more efficient) by adding a layer of in-direction > w.r.t how > HTLCs are manifested within the commitment transactions. To do this, we > add a > new 2-of-2 multi-sig output (an HTLC indirect block) to the commitment > transactions. This is then spent by a new transaction (the HTLC block) that > actually manifests (creates the HTLC outputs) the HTLCs. > > With this change, the cost to have a commitment be mined in the chain is > now > _independent of the number of HTLCs in the channel_. In the past I've > called > this construction "coupe commitments" (lol). > > Other flavors of this technique are possible as well, allowing both sides > to > craft varying HTLC indirection trees (double layers of indirection are > possible, etc) which may factor in traits like HTLC expiration time (HTLCs > that > expire later are further down in the tree). > > Something like CTV does indeed make this technique more powerful+efficient > as > it allows one to succinctly commit to all the relevant desirable > combinations > of HTLC indirect blocks, and HTLC fan-out transactions. > > -- Laolu > > > On Sat, Jun 20, 2020 at 4:14 PM Jeremy <jlru...@mit.edu> wrote: > >> 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.ri...@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@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@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 >> >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
