Trivial: user_channel_id in pending_claims_to_replay
What the developer wrote
Authored by Valentine Wallace
Trivial: user_channel_id in pending_claims_to_replay
Adds support for passing user_channel_id into the pending_claims_to_replay vec,
which is used by the ChannelManager on startup.
For now user_channel_id is always set to None, but in upcoming commits we will
set it to Some when the downstream channel is still open (this is currently a
bug). Separated out here for reviewability.
What changed, and why it matters
This is a small internal code cleanup in the Lightning Dev Kit's channel manager. It adds a placeholder field called user_channel_id to a list of pending payment claims that get replayed when the node starts up. The commit explicitly says the field is always set to None for now and that a future change will actually populate it. There is no security-relevant behavior change in this patch itself.
No security action needed for this commit. Monitor the follow-up commits that the message references, which will populate user_channel_id to Some when the downstream channel is still open.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The commit modifies lightning/src/ln/channelmanager.rs to thread an extra tuple element (user_channel_id) through pending_claims_to_replay. It updates tuple construction, pattern matching, and destructuring sites, and passes downstream_user_channel_id into a downstream claim method instead of a hardcoded None. However, every construction site still passes None, so the functional behavior is identical to before. The commit message frames this as preparation for a future bug fix.
Changed components
lightning/src/ln/channelmanager.rsInspect captured patch +5 / −3
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index cc95424..ac2af35 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -18988,7 +18988,7 @@ impl<
Some((htlc_source, payment_preimage, htlc.amount_msat,
is_channel_closed, monitor.get_counterparty_node_id(),
- monitor.get_funding_txo(), monitor.channel_id()))
+ monitor.get_funding_txo(), monitor.channel_id(), None))
} else { None }
} else {
// If it was an outbound payment, we've handled it above - if a preimage
@@ -19354,7 +19354,7 @@ impl<
{
for (prev_hop, outbound_amt_msat) in forwarded_htlcs {
let new_pending_claim =
- !pending_claims_to_replay.iter().any(|(src, _, _, _, _, _, _)| {
+ !pending_claims_to_replay.iter().any(|(src, _, _, _, _, _, _, _)| {
matches!(src, HTLCSource::PreviousHopData(hop) if hop.htlc_id == prev_hop.htlc_id && hop.channel_id == prev_hop.channel_id)
});
if new_pending_claim {
@@ -19379,6 +19379,7 @@ impl<
counterparty_node_id,
monitor.get_funding_txo(),
*channel_id,
+ None,
));
}
}
@@ -19648,6 +19649,7 @@ impl<
downstream_node_id,
downstream_funding,
downstream_channel_id,
+ downstream_user_channel_id,
) in pending_claims_to_replay
{
// We use `downstream_closed` in place of `from_onchain` here just as a guess - we
@@ -19663,7 +19665,7 @@ impl<
downstream_node_id,
downstream_funding,
downstream_channel_id,
- None,
+ downstream_user_channel_id,
None,
None,
);
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.