Bastien TEINTURIER [ARCHIVE] on Nostr: 📅 Original date posted:2023-05-05 🗒️ Summary of this message: The ...

📅 Original date posted:2023-05-05
🗒️ Summary of this message: The introduction of dual funded transactions in lightning has created challenges in protecting against liquidity griefing attacks from malicious peers. An elegant solution is to never lock utxos used in dual funded transactions, but this falls short when using 0-conf. 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.
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230505/9638cc46/attachment-0001.html>;