Why, how, and when should an intermediate LN node terminate/resolve its HTLC(s) off-chain?

Question

I once heard an attack against LN, which was called "flood & loot": https://medium.com/blockchains-huji/flood-loot-a-systemic-attack-on-the-lightning-network-5c3dac7bba24

The 3rd step of that attack was described as follows:

III. Resolving payments on the last hop

After all payments were successfully routed and the HTLCs were added to the target node’s channels, the target node resolves all payments by returning the required secrets and claims these funds for himself. At that point, the target node could gracefully close his channels and leave with the funds sent by the source node. Once each victim acquires the secrets, he sends them back to the source node, asking to resolve the HTLCs and move their amount to the victim’s side of the channel. The source node refuses to resolve the payments and ignores any further messages from his victims.

So what does "resolve the HTLC" here mean? I see a mechanism titled "HTLC Off-chain Termination" in the LN whitepaper - does the term "resolving" here refer to this mechanism?

If so, I then think that, resolving/terminating HTLCs of the target node off-chain gives the attacker advantage (or gives the victim disadvantage) when the HTLCs of the source node is not yet resolved/terminated off-chain. Because, once the HTLCs of the target node are resolved, the victim will completely rely on the HTLCs of the source node being executed (rather than expired/refunded) to merely avoid fund loss, at best, meanwhile, the attacker will profit by stealing fund from HTLC expiry/refund, even in the worst case the attacker still won't lose anything.

So, what if the victim node in the middle then refuses to resolve the HTLCs with the target node as well, as long as the source node refuses to resolve its HTLCs with the victim node in the first place?

Why, how, and when should an intermediate LN node terminate/resolve its HTLC(s) off-chain?

Answer 1

First I would recommend to read BOLT2 in the section normal channel operation in order to understand exactly how and when htlcs are resolved. The whitepaper is heavily outdated and only explains the principles.

That being said the problem of your question remains.

To answer your question : intermediate nodes should resolve HTLCs as quickly as possible but that depends on the outgoing peer.

Let us assume the following path :

A-->B-->C-->D

As soon as D resolves the HTLC off chain C should resolve with B. And B should then resolve with A. The problem occurs if A stops talking to B. In that case B cannot resolve its HTLCs while it paid C who has was reimbursed to pay D before. Unluckily B can only resolve its HTLC with A after it resolved the HTLCs with C. The idea of doing it the other way around would not work and remove the trustless property of the routing.

In theory this should not be a problem for B as B can trigger a force close of the channel and resolve the HTLCs onchain. This however yields several practical questions which can lead to the described attack:

• what if the timelocks of the HTLCs expire soon? (Then A can claim those time locked outputs)
• what if the mempool is full and fees are high? First B has to pay those fees in order to get its HTLC included and settled however once the timelock is over A could also claim those outputs with higher fees. In case A and D collaborate A has as much money as the HTLC is worth.
• getting the commitment transaction in before the htlc timelock expires might become tricky as the fees of commitment tx are prenegotated and if A stops talking can't be adopted.

The third point might lead to the scenario of the second which can lead to the first. In such cases weired effects can happen and B can lose its funds that are in the HTKC as B has paid C but won't get reimbursed by A even though it has the proper signed onchain transactions.

A node generally does not want to force close the channel as that is expensive. Especially if that nodes expects to claim htlc outputs. However if the htlc timelock gets to close the node should consider to already close the channel to get the commitment txcinfirmed and be better prepared in the sense of having a time window to to get its HTLCs resolved without A being able to interfere.

Sorry that I can't give you a definite answer here. That is exactly part of the problem / attack and makes it so subtle