Hey Antoine, Sure, I agree with you, the usual mempool pinning issues still apply regardless of whether we use 0-conf or not. And we must solve them all at some point!
I think a reasonable mid-term solution is to use v3 transactions for channel funding and splicing, with the obvious caveat that it makes them identifiable on-chain (unless in the longer term, everyone moves to v3 transactions for everything, which doesn't seem crazy to me?). In the longer term, we know that some kind of anti-DoS token will need to be exchanged to avoid this whole class of issue, but as we've often discussed this isn't an easy thing to design and analyze... > 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. Sure, that's a policy that nodes can decide to apply if they want to, and it should be simple enough to implement (no protocol changes are needed). Thanks, Bastien Le mer. 7 juin 2023 à 02:41, Antoine Riard <antoine.ri...@gmail.com> a écrit : > 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
