Consider failing HTLC backwards before upstream claims on-chain

[TheBlueMatt]

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.

[dunxen]

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]

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]

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]

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.

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]

It seems to me you say in reverse. Forgive me my English if I'm wrong.

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]

Asked @dunxen about this offline, gonna pick this one up.

Wanted to lay out the situation to make sure I'm getting this right:

• Downstream counterparty force-closes to claim HTLC-success
  • If it confirms before our timeout → we claim upstream
• We reach our timeout for the downstream channel
  • We broadcast our txs
  • If one of them confirms before upstream timeout → simply fail/claim upstream
• If we’re getting close to our upstream timeout and nothing’s confirmed yet (we don’t account for this case right now, right?)
  • (anchors) Can we (or do we already) fee bump to prevent us from even getting here?
  • Otherwise, make a decision:
    • If HTLC is small - just fail back, don’t lose the upstream channel
      • Hope we win the race on the downstream tx, if not then we lose only a small HTLC
    • If HTLC is large - don’t fail back, let the upstream channel force close
      • Hope we win the race on the downstream tx, if not then we at least have the chance of claiming upstream

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]

Okay, after thinking about this more, I’m leaning towards just failing back if we reach some X blocks before the upstream timeout.

it doesn't really change the resolution of the upstream HTLC.

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]

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.