Repository navigation
Allow non-strict forwarding for spliced/closed channels #3821
Description
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
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.
Activity
jkczyz commentedon Jun 2, 2025
For spliced channels, I believe this will work as implemented in #3741 (b65c073).
tnull commentedon Jun 3, 2025
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 commentedon Jun 3, 2025
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
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_channelis called.joostjager commentedon Jun 3, 2025
Maybe it would have been nice to have pubkey routing lightning/bolts#814 now? Side remark.
jkczyz commentedon Jun 16, 2025
Hmm... can't tell how this was linked to #3741. Don't we still have a problem for closed channels? (cc: @TheBlueMatt)
TheBlueMatt commentedon Jun 30, 2025
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 commentedon Jul 1, 2025
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 commentedon Jul 1, 2025
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 commentedon Jul 1, 2025
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 commentedon Jul 2, 2025
#3902 should address the issue for blinded paths when splicing is in use, I believe.