Repository navigation
Consider failing HTLC backwards before upstream claims on-chain #2275
Description
One thing we've always done is wait to fail an HTLC backwards until the upstream is claimed, even if the upstream is waiting on an on-chain claim that takes much longer than the downstream HTLC has time left. This can lead to a force-closure of the downstream channel, though only if our upstream channel force-closed and failed to claim in time.
Its unclear what the best course of action is here, totally giving up on the backwards edge before being sure we have the forwards edge figured out sucks, but losing the channel entirely just because we're waiting probably sucks more.
Metadata
Metadata
Assignees
Labels
No labels
Activity
dunxen commentedon May 8, 2023
Would this need to be based on a proportional risk dependent on HTLC value?
Having a delayed claim of a “low-value” HTLC risking closing the downstream channel seems pretty nasty especially in a high fee environment, but losing a “high-value” HTLC seems equally dreadful.
TheBlueMatt commentedon May 8, 2023
Yea, that's a third option. We should probably figure out exactly what waiting buys us - we force the upstream channel to chain (by making our counterparty close it), basically, and then make our counterparty claim via their HTLC-Timeout, which probably gives us a few extra blocks to get our upstream HTLC-Timeout in, but it doesn't really change the resolution of the upstream HTLC. Unless we get a super-duper-last-minute preimage on the downstream channel on-chain, presumably due to some pinning something, it'll eventually time-out, and even if we do get such a preimage, we may not be able to claim it upstream anyway because upstream is already on-chain (and we're not doing a pinning attack).
TheBlueMatt commentedon May 10, 2023
Saw some plebnet folks see this exact failure lead to a force-close with lnd nodes (apparently they do the same thing we do), so its not totally unrealistic.
yuyaogawa commentedon Jun 15, 2023
Consider an HTLC chain as following,
A -> B -> C
B has incoming and outgoing HTLCs. Do you mean upstream is A and downstream is C? It seems to me you say in reverse. Forgive me my English if I'm wrong.
Another question is that does it avoid a cascade of FCs to add an anchor output in the HTLC_timeout_tx so that Bob can fee-bump?
TheBlueMatt commentedon Jul 2, 2023
Err, yes, sorry, I mis-spoke here. I am referring to the case where we're B and the B <-> C channel is force-closed but hasn't yet confirmed on-chain. HTLCs which are waiting in that channel we can consider failing on the A <-> B channel if they're close to expiring.
We should do this, but since it hasn't happened yet, 117.
alecchendev commentedon Jul 21, 2023
Asked @dunxen about this offline, gonna pick this one up.
Wanted to lay out the situation to make sure I'm getting this right:
I still have to think about how to decide how big an HTLC needs to be to pass this threshold but does this seem reasonable?
alecchendev commentedon Jul 23, 2023
Okay, after thinking about this more, I’m leaning towards just failing back if we reach some X blocks before the upstream timeout.
I think what was said above here makes sense, it seems to me that if we get to a point where our upstream timeout expires and our downstream is still awaiting confirmation, it doesn’t help to have our upstream channel force close. If we get the preimage after our upstream channel force closes, we can't claim off-chain, and the odds of using that preimage to claim on-chain are not in our favor. So we’re probably losing that HTLC anyway, might as well keep the channel. I might try and calculate how big an HTLC would have to be to be an exception to this case, but to start, I’m thinking the majority of the time we're probably better off keeping the channel.
Will try and open a PR with this approach this week unless someone says otherwise :)
TheBlueMatt commentedon Aug 31, 2023
We should try to do this soon, but I'm not sure its now (with more predictable feerates) the highest priority to get in before 0.0.117, so releasing the milestone.
TheBlueMatt commentedon Dec 5, 2024
As always, when fees are calm we push off work that only matters when fees spike, at which point its too late. Sadly, we just have too many priorities right now :(
TheBlueMatt commentedon Dec 7, 2024
Actually, it would be nice to fix this sooner, but I'm not sure it makes sense to hold 0.1 on it because this isn't a regression. Instead, we might lean into backport releases now that our version number allows for it, and put this in an 0.1.1