Allow non-strict forwarding for spliced/closed channels

[tnull]

In #3127 we implemented non-strict forwarding which allows us to forward over substitute channels with preferable liquidity state.

However, if we have an HTLC incoming for a channel with short_channel_id we don't know (e.g., spliced, recently-closed), we simply give up (

rust-lightning/lightning/src/ln/channelmanager.rs

Line 6046 in 8aae34e

forwarding_channel_not_found!(pending_forwards.drain(..));

) as we don't have data on the counterparty.

It would be nice if we could have some datapoints stick around after channels have been closed/spliced so that we can expand non-strict forwarding for these cases: simply forward over a substitute channel with the same peer, even if the original channel is gone by now.

[jkczyz]

For spliced channels, I believe this will work as implemented in #3741 (b65c073).

[tnull]

For spliced channels, I believe this will work as implemented in #3741 (b65c073).

Ah, IIUC, you're saying this could be done post-#3741, right, but we'd still need changes to look up the counterparty and continue the forwarding path, right?

[jkczyz]

The code you linked in the description is looking up using self.short_to_chan_info:

rust-lightning/lightning/src/ln/channelmanager.rs

Line 6042 in 8aae34e

let chan_info_opt = self.short_to_chan_info.read().unwrap().get(&short_chan_id).cloned();

In #3741, the old SCIDs for spliced channels are kept in that map for 12 blocks and are mapped to the corresponding FundedChannel, which doesn't change when the channel is spliced. So, IIUC, that look-up should work for the old SCIDs (i.e., nothing else is needed to support spliced channels).

For closed channels, we'll need do something else since the current SCID (and any remaining old SCIDs if the channel had been spliced) are removed when the channel is closed when locked_close_channel is called.

[joostjager]

Maybe it would have been nice to have pubkey routing lightning/bolts#814 now? Side remark.