Knots/Core chain split, HTLC strip risk for routing nodes

[racarr202]

Preamble:

With the BIP-110/RDTS activation window approaching, a persistent chain split between Core and Knots is looking increasingly plausible. Current signaling for the Knots position is low, but there is also no indication of a back down.
This post is NOT about the merits of either position.
I want to have a technical question about how LND routing nodes should manage a specific failure mode that would be relevant to any chain split scenario.

I'm a bit surprised this isn't being discussed more widely among routing node operators so if I'm missing something obvious, I'd welcome any correction.

---

The scenario:

Consider a node forwarding Alice → Routing Node → Bob at fork height. The two HTLCs that make up this in-flight payment — one with Alice, one with Bob — both exist on both chains, since both channels were funded pre-fork.

If Bob's LND is following Chain B and he force-closes, he claims the outgoing HTLC on Chain B, revealing the preimage there. The routing node is watching Chain A and never witnesses the preimage. The incoming HTLC times out on Chain A and Alice is refunded there.

The critical point is that the routing node never learns the preimage at all — not on either chain. This means it also fails to claim Alice's HTLC on Chain B before it expires. Alice is therefore refunded on Chain B as well. The Chain B ledger settles as follows: Bob received his funds, Alice received her refund, and the routing node paid out to Bob but collected nothing from Alice.

This loss is permanent regardless of which chain ultimately wins. If Chain B becomes the dominant chain, the routing node inherits a ledger on which it has already lost the forwarded amount. Switching chains later does not reverse an outcome that is already written into Chain B's history.

The standard timelock asymmetry protection (T_outgoing < T_incoming) is chain-scoped. It assumes preimage revelation happens on the same chain the routing node is watching. That assumption breaks across a split.

---

Known mitigations:

• rejecthtlc=true
• requireinterceptor=true — Used with some form of custom script to block HTLC's as the fork height approaches.
• Reduce max-cltv-expiry in the weeks prior to drain long-duration HTLC's, then flip rejecthtlc=true before fork height.

---

What I'm looking for:

• Other than the above is anyone aware of existing logic in LND to detect a chain split condition and respond automatically?
• Are there mitigations beyond the flags above that operators should know about?
• What are other routing node operators actually planning to do in this regard?

This feels like a risk that warrants broader discussion among operators before we're inside the activation window. Keen to hear what others are thinking.

[SunnySarahNode]

I'm genuinely surprised that this topic doesn't seem to interest anyone both here and in different communities.

At the same time many operators even prefer to close their nodes for the period of a possible BIP-110 fork and plan to reopen them later. Others are going to stop routing. Others simply don't know what to do and going to do nothing and take risks they don't even understand.

• How to avoid ending up on the wrong chain?
• How to get access to the coins on the other chain (in channels, i.e. without private keys)?
• When and how do we need to upgrade our BTC client in different scenarios?
• What should we do at least in the baseline scenario to mitigate risks?
• ...and so on, so many unanswered questions.

I would be grateful for ANY information in the context of the Lightning Network relative to the BIP-110 fork.

[SunnySarahNode]

I was sent a very good article that might be very useful or at least interesting:

• Lightning and BIP-110: How to not lose Sats while everyone else argues

UPD: another great resources:

• What Does BIP110 Mean for the Lightning Network? (thanks to Amboss)

• BIP110 Fork Simulator