How is a timelock attack on forwarding nodes mitigated by lightning?

[fresheneesz]

If an attacker pays themselves through honest nodes and the payee node refuses to relay the secret, they can lock up funds for honest nodes for the timeout period without spending any money. It seems the attacker would only need to be willing to lock as much of its own capacity as the victim node with the largest capacity it wants to target. See here for details.

Is this currently mitigated? If not, how could it be?

[t-bast]

This is indeed a known issue with the current multi-hop payment design.
The reason this is not critical in the short term is that as you mention, the attacker also has to lock some capacity to carry out this attack.
But I agree this will need to be mitigated at some point.

[t-bast]

Some discussions around this issue (back from 2015):

• https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html
• https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001232.html

And this issue: #182

[fresheneesz]

Ah those are some very interesting discussions. Should I close this in favor of #182 then?

I have some interesting thoughts that came out of a recent discussion I've been having. I think I might have an interesting solution #4 to add to the list that is somewhat along the lines of a "reputation system" that a couple people mused about. I'll add those thoughts to #182.

[t-bast]

Ah those are some very interesting discussions. Should I close this in favor of #182 then?

Yes please, let's centralize this in #182.

I have some interesting thoughts that came out of a recent discussion I've been having. I think I might have an interesting solution #4 to add to the list that is somewhat along the lines of a "reputation system" that a couple people mused about. I'll add those thoughts to #182.

Great, thanks for sharing this!

[cfromknecht]

@fresheneesz another thing to consider is that, in your example, the funds in the path or only timelocked until the expiry of the final hop. after that hop gets failed, the remaining hops are settled immediately off chain all the way back to the sender.

more generally, if hops i and j are delaying in a path S -> i -> ... -> j -> R, the funds for hops between i and j are only timelocked until hop j's timelock expires.

[fresheneesz]

@cfromknecht Yes, but those time locks can be long (hours), right? The idea is to have a way to disincentivize channels that cause those long locks. Also, I'm not sure what you mean by "i and j are delaying" - if node j delays sending the HTLC, then nodes S through j-1 are all locked up. There's no way to lock up the nodes between i and j without locking up nodes through to S.