Select the channel with the highest balance for blinded paths
What the developer wrote
Authored by Matt Corallo
Select the channel with the highest balance for blinded paths
When building a compact blinded path we need to pick a channel for
an SCID that we think is mostl likely to stick around the longest.
We don't really have any great options cause we have no idea what
downstream code does, but "highest balance" seems marginally
better than the previous criteria of "oldest channel".
What changed, and why it matters
This commit changes how the Lightning node picks which payment channel to advertise when creating compact 'blinded paths' for private routing. Previously it picked the oldest channel; now it picks the channel with the highest local balance. The stated goal is to choose a channel most likely to remain open and usable, improving reliability of incoming payments rather than fixing a security flaw.
No immediate security action required. Treat as a normal reliability/performance improvement. Review whether the new heuristic could leak balance information or affect path liveness, but the commit itself does not present a clear vulnerability.
Security signals we found
Heuristic change in channel selection for blinded path advertisement
No cryptographic, authorization, or memory-safety changes
No explicit security relevance stated in commit message
No incident or vulnerability disclosure referenced
Evidence from the diff
In channelmanager.rs, two channel-selection heuristics for compact blinded paths are changed from minimum age/SCID to maximum local balance (inbound_capacity_msat and get_value_to_self_msat()). This is a heuristic change in path advertisement logic. It does not modify cryptographic checks, authorization, memory safety, or transaction validation. The diff shows no bounds checks, no input sanitization, and no privilege changes.
Changed components
lightning/src/ln/channelmanager.rsCompact blinded path constructionInbound channel SCID selectionInspect captured patch +6 / −2
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index 64cbc92..3bc105d 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -14085,7 +14085,9 @@ impl<
short_channel_id: peer_chans
.iter()
.filter(|chan| chan.is_usable)
- .min_by_key(|chan| chan.short_channel_id)
+ // Select the channel which has the highest local balance. We assume this
+ // channel is the most likely to stick around.
+ .max_by_key(|chan| chan.inbound_capacity_msat)
.and_then(|chan| chan.get_inbound_payment_scid()),
})
}
@@ -14108,7 +14110,9 @@ impl<
.iter()
.filter(|(_, channel)| channel.context().is_usable())
.filter_map(|(_, channel)| channel.as_funded())
- .min_by_key(|funded_channel| funded_channel.context.channel_creation_height)
+ // Select the channel which has the highest local balance. We assume this
+ // channel is the most likely to stick around.
+ .max_by_key(|funded_channel| funded_channel.funding.get_value_to_self_msat())
.and_then(|funded_channel| funded_channel.get_inbound_scid()),
})
.collect::<Vec<_>>()
Why this scored 23/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.