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.

[jkczyz]

Hmm... can't tell how this was linked to #3741. Don't we still have a problem for closed channels? (cc: @TheBlueMatt)

[TheBlueMatt]

Ah, I missed the comment about closed channels, as it works for splices. Probably post-splicing it won't be a big deal cause you'll never close a channel, just splice to keep a single channel with a peer :)

[tnull]

Ah, I missed the comment about closed channels, as it works for splices. Probably post-splicing it won't be a big deal cause you'll never close a channel, just splice to keep a single channel with a peer :)

Maybe, but this could only happen if the counterparty actually supported splicing. Given that we don't have a good understanding when the entire network will be splicing-ready, I think it makes sense to fix/handle the closing case independently, even if it would longer-term only benefit 'legacy' channels.

[joostjager]

This also came up in review of async payments. If the recipient remains offline and doesn't refresh the invoices that are served by the static invoice server on their behalf, there might be outdated paths in there. Even if the invoice is fresh, the recipient may go offline directly after. The hold/release mechanism may come into effect sender-side, and only forward the htlc at a later time.

I wonder if 12 blocks is enough? Why not keep all the previous chan ids? It is limited by block space. Or keep all the previous chan ids within a period of time ie one month.

Or just route to a node by using its node key truncated to 8 bytes as the short chan id, which probably solves all of this in a much simpler way.

[jkczyz]

FWIW, the spec change landed on 72 blocks (lightning/bolts#1270) and we decided to double it to 144 in #3873. We probably want some sort of limit since we are persisting the data, though the truncation approach seems like an appealing alternative.

[TheBlueMatt]

#3902 should address the issue for blinded paths when splicing is in use, I believe.