ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2023-05-09 📝 Original message: Good morning Matt, and ...
📅 Original date posted:2023-05-09
📝 Original message:
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 <mattmorehouse at 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 bastien at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
📝 Original message:
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 <mattmorehouse at 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 bastien at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev