JIT/HTLC Interception - Failed payment attack

[SeverinAlexB]

Issue #3 proposes two different ways to implement Just-In-Time (JIT) channel openings. JIT are an important feature especially for mobile wallets.

Option a) and b) proposed in the issue, are both vulnerable to an attack I call here the "Failed payment attack". This vulnerability allows an attacker to make the LSP open a channel without it being paid a fee.

Here I will show how such an attack could look like and potential mitigations.

Attack description

Prerequisits

The attacker owns 2 nodes:

• A funded node with at least 1 funded channel.
• A receiver node that the LSP opens a channel to.

Base attack

1. The receiver node registers an incoming payment at the LSP.
2. The receiver node sends the invoice to the funded node.
3. The funded node pays the invoice.
4. The LSP recognizes the incoming payment and opens a turbo-channel to the receiver node.
5. The LSP forwards the HTLC to the receiver node.
6. The receiver node rejects the HTLC and therefore fails the payment.

In this case, the attacker made the LSP open a channel without a fee.

Systematic attack

The base attack can be turned into a systematic attack cheaply.
Multiple receiver nodes can be created without any costs as they need zero funded channels. The funded node can be reused. The used HTLC recovers instantly because the receiver node failed the payment. Due to LN sender privacy, the funding node stays anonymous.

Therefore the attacker can repeat the base attack as often as they want without any costs. They can make the LSP open a huge number of channels without it being able to charge a fee and therefore inflict huge costs on it. In case the receiver node refuses to coporatively close the channel, the funds will be stuck in limbo multiple days blocking the LSP onchain funds.

Mitigations

I define two potential attackers here.

• a) Regular users that want a free channel.
• b) LSP competitor or state-level actor.

I am mostly concerned about b).

Potential mitigations

1. Close the channel instantly again. This prevents (a) from using the channel and therefore gaining anything from the attack.
2. Hold the HTLC for several hours in case the payment fails. This could potentially slow down (b) but will not stop them.
3. Share the preimage with the LSP when the receiver node registers the payment initially. This would shift the problem from the receiver node (can fail the HTLC) to the LSP (can just claim the HTLC without opening a channel). This would effectively prevent (a) and (b) but give the LSP a lot of power. In an environment where LSPs have to keep a good reputation, this could be a workable solution.

Personal note

I believe this attack has a good potential to be abused by either competitors or state-level actors. The costs are high especially with high on-chain fees. We should think about mitigations.

Maybe somebody comes up with a better mitigation strategy than 3. Sharing the preimage but so far I see this as
the most practical solution. 3. is far from perfect.

Severin

[SeverinAlexB]

Some additional inputs:

• Zero-conf channels already require a certain trust in the LSP.
• Rate limiting can limit the costs that an attacker can inflict on the LSP. At the same time, it makes it easier to run a Denial of Service on the LSP.

[ZmnSCPxj-jr]

See also: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-May/003939.html (not a reliable fix, by the way).