Re: [Lightning-dev] Liquidity griefing for 0-conf dual-funded txs
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 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 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
Re: [Lightning-dev] Liquidity griefing for 0-conf dual-funded txs
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 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
Re: [Lightning-dev] Liquidity griefing for 0-conf dual-funded txs
Hey Matt, Zman, > 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. While this is true for dual funding, this isn't true for splicing, where we need the remote `tx_signatures` to spend the channel's current funding output. But it's not an issue, the untrusted peer will send their `tx_signatures` first (since they're not contributing to the transaction) and we can `TryLock()` once we receive that. > 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. I also thought that this was the easy way out, but I was hoping we could do better. The issue with that option (using v1 with locks for 0-conf, and v2 with soft locks for non 0-conf) is that we need to implement that soft lock mechanism (we cannot simply rely on bitcoin core, which only supports hard locks) or use separate bitcoin core wallets for 0-conf and non 0-conf. But there is probably no free lunch here! And anyway, this post was also made to raise awareness for implementers to make sure they don't end up accidentally double-spending 0-conf channels when implementing dual funding. Thanks, Bastien Le mer. 10 mai 2023 à 02:07, ZmnSCPxj a écrit : > 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 > > >
Re: [Lightning-dev] Liquidity griefing for 0-conf dual-funded txs
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 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) >
Re: [Lightning-dev] Liquidity griefing for 0-conf dual-funded txs
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 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
Re: [Lightning-dev] Liquidity griefing for 0-conf dual-funded txs
Good morning t-bast, and list, Dual-funded 0-conf can be made safe in the following case: * If the initiator uses swap-in-potentiam addresses (with initiator as Alice, acceptor as Bob). If the initiator stalls, then the acceptor can retaliate by refusing to sign the swap-in-potentiam UTXOs forever after that, thus also locking their funds until the swap-in-potentiam times out, thus preventing this liquidity griefing from being cost-free. The expected use-case is that a user expects onchain operations to be slow and take multiple confirmations to receive. Once there is deep confirmation that a swap-in-potentiam address has been funded, then it can be transferred immediately to a 0-conf Lightning channel. The initiator still needs to trust that the acceptor does not double-spend out from under the initiator, but see LSPS3 Promise To Unconditionally Fund 0-conf. Also, it looks like you are allowing for the initiator to trust the acceptor in that case, as I believe you are taking the point of view of the acceptor of the dual-funding flow. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Liquidity griefing for 0-conf dual-funded txs
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
