Good morning Matt, and t-bast, Your proposal basically means "do not dual-fund 0-conf". You might as well use the much simpler openv1 flow in that case, just because it is simpler.
Regards, ZmnSCPxj Sent with Proton Mail secure email. ------- Original Message ------- On Tuesday, May 9th, 2023 at 5:38 PM, Matt Morehouse <mattmoreho...@gmail.com> wrote: > Hi Bastien, > > In general, 0-conf is only safe when WE are the only contributor to > the channel, otherwise the peer could double spend us. > > The problem you seem to be describing is that we might double-spend > ourselves if we don't lock our 0-conf UTXOs at some point. I propose > that we DO lock our UTXOs after tx_completes have been exchanged IF we > are the only contributor. We don't have to worry about liquidity > griefing in this case, since the peer has no tx_signatures to withhold > from us. Of course, the opportunistic upgrade of a regular channel to > 0-conf won't work -- we need a way to differentiate 0-conf channels > prior to UTXO selection, so that we don't reuse soft-locked UTXOs. > > All together, what I propose is: > > 1) If the channel type has option_zeroconf, select UTXOs that are not > soft locked. > 2) If the peer adds any inputs to the funding transaction, abort > (0-conf is unsafe for us in this case). > 3) After tx_complete exchange, TryLock() our UTXO inputs and abort if > already locked. > 4) Broadcast funding transaction and begin using the 0-conf channel. > > I think this at least enables the common use case for 0-conf: LSPs can > use their own funds to open 0-conf channels for clients. > > - Matt > > > > > On Sat, May 6, 2023 at 3:16 AM Bastien TEINTURIER bast...@acinq.fr wrote: > > > 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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
