Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2023-06-06 🗒️ Summary of this message: The Lightning ...
📅 Original date posted:2023-06-06
🗒️ Summary of this message: The Lightning Network may be vulnerable to liquidity griefing, where a counterparty locks up resources without paying fees. A "soft lock" strategy may not be enough to prevent this, and other solutions, such as the Staking Credentials framework, may need to be explored.
📝 Original message:
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 <bastien at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230607/50378bc7/attachment.html>;
🗒️ Summary of this message: The Lightning Network may be vulnerable to liquidity griefing, where a counterparty locks up resources without paying fees. A "soft lock" strategy may not be enough to prevent this, and other solutions, such as the Staking Credentials framework, may need to be explored.
📝 Original message:
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 <bastien at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230607/50378bc7/attachment.html>;