LN forwarding: if outgoing channel is force-closed, we should fail/fulfill htlcs on incoming channel, even if the htlcs do not appear in the commitment tx

[SomberNight]

#9628 did not fully fix #8547

Consider an A->B->C forwarding, from the PoV of B.

The issue with #9628 is that it only looks at HTLCs that have an output in the commitment tx of the BC channel. There are multiple reasons why an HTLC might not appear in the ctx but still be "active" on the channel:

• the htlc might be below the dust limit
• the htlc might not have been irrevocably added yet to the BC channel (but it already has an output in the AB channel's ctx)

---

The CLTV at the B->C link is e.g. at height 100, and the CLTV at the A->B link is at height 200. At block 101 we have B force-close the B->C channel if C has not timed out the htlc yet.

After the BC channel force-closure and the htlc-timeout tx are sufficiently deeply mined, Bob should send update_fail_htlc to Alice. Note that it can also happen that when Bob force-closes BC, Carol suddenly appears and broadcasts an htlc-success tx to spend the htlc on-chain. In that case Bob does not need to wait for confirmations: he could just extract the preimage and fulfill the htlc on the AB channel.

In any case, Bob should propagate back the removal (either fulfill or fail) of the HTLC to the AB channel, even if the HTLC does not appear in the commitment tx that closed the BC channel.

---

See BOLT-5, which explicitly mentions this:

https://github.com/lightning/bolts/blob/216914d492ecdf8a814bbab34fa9f6d31b394b98/05-onchain.md?plain=1#L255-L261

• for any committed HTLC that does NOT have an output in this commitment
  transaction:
  • if the payment preimage is known:
    • MUST fulfill the corresponding incoming HTLC (if any).
  • otherwise:
    • once the commitment transaction has reached reasonable depth:
      • MUST fail the corresponding incoming HTLC (if any).

---

Re implementation, note that the current logic is part of chan.extract_preimage_from_htlc_txin, which looks at a specific txin, and is called by lnwatcher. So this naturally only looks at htlcs that appear onchain.

Compare that to chan.should_be_closed_due_to_expiring_htlcs, which is called by lnworker.handle_onchain_state, which simply enumerates all active htlcs via chan.hm (the HTLCManager).