Hi Bastien, > This can be fixed by using a "soft lock" when selecting utxos for a non > 0-conf funding attempt. 0-conf funding attempts must ignore soft locked > utxos while non 0-conf funding attempts can (should) reuse soft locked > utxos.
If my understanding of the "soft lock" strategy is correct - Only locking UTXO when it's a non 0-conf funding attempt - I think you're still exposed to liquidity griefing with dual-funding or splicing. The vector of griefing you're mentioning is the lack of signature release for a shared input by your counterparty. However, in the context of dual-funding where the counterparty can add any output with `tx_add_output`, the transaction can be pinned in the mempool in a very sneaky way e.g abuse of replacement rule 3. This latter pinning vector is advantageous to the malicious counterparty as I think you can batch your pinning against unrelated dual-funding, only linked in the mempool by a malicious pinning CPFP. It is left as an exercise to the reader to find other vectors of pinnings that can be played out in the dual-funding flow. In terms of (quick) solution to prevent liquidity griefing related to mempool vectors, the (honest) counterparty can enforce that any contributed outputs must be encumbered by a 1 CSV, unless being a 2-of-2 funding. Still, this mitigation can be limited as I think the initial commitment transaction must have anchor outputs on each-side, for each party to recover its contributed UTXOs in any case. > Then we immediately send `channel_ready` as well and start using that > channel (because we know we won't double spend ourselves). This is nice > because it lets us use 0-conf in a way where only one side of the > channel needs to trust the other side (instead of both sides trusting > each other). >From the 0-conf initiator viewpoint (the one contributing the UTXO(s)), it can still be valuable to disable inbound payments, or requires a longer `cltv_expiry_delta` than usual, in case of mempool fee spikes delaying the 0-conf chain confirmation. Beyond, it sounds liquidity griefing provoked by a lack of signature release or mempool funny games will always be there ? Even for the second with package relay/nVersion deployment, there is still the duration between the pinning happening among network mempools and your replacement broadcast kickstarts. As a more long-term solution, we might reuse solutions worked out to mitigate channel jamming, as the abstract problem is the same, namely your counterparty can lock up scarce resources without (on-chain/off-chain whatever) fees paid. E.g the Staking Credentials framework could be deployed by dual-funding market-makers beyond routing hops [0]. The dual-funding initiator should pay to the maker a fee scale up on the amount of UTXOs contributed, and some worst-case liquidity griefing scenario. A privacy-preserving credential can be introduced between the payment of the fee and the redeem of the service to unlink dual-funding initiators (if the maker has enough volume to constitute a reasonable anonymity set). Best, Antoine [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003964.html Le sam. 6 mai 2023 à 04:15, Bastien TEINTURIER <bast...@acinq.fr> a écrit : > Good morning list, > > One of the challenges created by the introduction of dual funded > transactions [1] in lightning is how to protect against liquidity > griefing attacks from malicious peers [2]. > > Let's start by reviewing this liquidity griefing issue. The dual funding > protocol starts by exchanging data about the utxos each peer adds to the > shared transaction, then exchange signatures and broadcast the resulting > transaction. If peers lock their utxos as soon as they've decided to add > them to the shared transaction, the remote node may go silent. If that > happens, the honest node has some liquidity that is locked and unusable. > > This cannot easily be fixed by simply unlocking utxos *after* detecting > that the remote node is fishy, because the remote node would still have > succeeded at locking your liquidity for a (small) duration, and could > start other instances of that attack with different node_ids. > > An elegant solution to this issue is to never lock utxos used in dual > funded transactions. If a remote node goes silent in the middle of an > instance of the protocol, your utxos will automatically be re-used in > another instance of the protocol. The only drawback with that approach > is that when you have multiple concurrent instances of dual funding with > honest peers, some of them may fail because they are double-spent by one > of the concurrent instances. This is acceptable, since the protocol > should complete fairly quickly when peers are honest, and at worst, it > can simply be restarted when failure is detected. > > But that solution falls short when using 0-conf, because accidentally > double-spending a 0-conf channel (because of concurrent instances) can > result in loss of funds for one of the peers (if payments were made on > that channel before detecting the double-spend). It seems like using > 0-conf forces us to lock utxos to avoid this issue, which means that > nodes offering 0-conf services expose themselves to liquidity griefing. > > Another related issue is that nodes that want to offer 0-conf channels > must ensure that the utxos they use for 0-conf are isolated from the > utxos they use for non 0-conf, otherwise it is not possible to properly > lock utxos, because of the following race scenario: > > - utxoA is selected for a non 0-conf funding attempt and not locked > (to protect against liquidity griefing) > - utxoA is also selected for a 0-conf funding attempt (because it is > found unlocked in the wallet) and then locked > - the funding transaction for the 0-conf channel is successfully > published first and that channel is instantly used for payments > - the funding transaction for the non 0-conf channel is then published > and confirms, accidentally double-spending the 0-conf channel > > This can be fixed by using a "soft lock" when selecting utxos for a non > 0-conf funding attempt. 0-conf funding attempts must ignore soft locked > utxos while non 0-conf funding attempts can (should) reuse soft locked > utxos. > > In eclair, we are currently doing "opportunistic" 0-conf: > > - if we receive `channel_ready` immediately (which means that our peer > trusts us to use 0-conf) > - and we're the only contributor to the funding transaction (our peer > doesn't have any input that they could use to double-spend) > - and the transaction hasn't been RBF-ed yet > > Then we immediately send `channel_ready` as well and start using that > channel (because we know we won't double spend ourselves). This is nice > because it lets us use 0-conf in a way where only one side of the > channel needs to trust the other side (instead of both sides trusting > each other). > > Unfortunately, we cannot do that anymore when mixing 0-conf and non > 0-conf funding attempts, because the utxos may be soft locked, > preventing us from "upgrading" to 0-conf. > > You have successfully reached the end of this quite technical post, > congrats! My goal with this post is to gather ideas on how we could > improve that situation and offer good enough protections against > liquidity griefing for nodes offering 0-conf services. Please share > your ideas! And yes, I know, 0-conf is a massive implementation pain > point that we would all like to remove from our codebases, but hey, > users like it ¯\_(ツ)_/¯ > > Cheers, > Bastien > > [1] https://github.com/lightning/bolts/pull/851 > [2] https://github.com/lightning/bolts/pull/851#discussion_r997537630 > _______________________________________________ > 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
