Fix off-by-one for unfunded channel peers
What the developer wrote
Authored by elnosh
Fix off-by-one for unfunded channel peers
When accepting channels manually, it would
fail if the # of peers without funded channels
was == `MAX_UNFUNDED_CHANNEL_PEERS`, however,
it should fail if the # of peers > `MAX_UNFUNDED_CHANNEL_PEERS`.
What changed, and why it matters
This commit fixes a small boundary error in how Lightning Dev Kit counts peers that have unfunded channels. Previously, the software rejected new channel requests one peer too early, meaning legitimate users could be blocked from opening a channel when they were exactly at the configured limit. The fix changes the comparison from 'greater than or equal to' to 'greater than' the limit, restoring the intended behavior.
No immediate security response is required. Users running code with manual channel acceptance should update to include this fix to avoid unnecessary rejection of legitimate channel opens at the unfunded-peer limit. Review whether the stricter-than-intended behavior caused any operational issues.
Security signals we found
Logic boundary error in resource-limit enforcement
Denial-of-service-like effect: legitimate channel open requests rejected prematurely
Fix is minimal and targeted at a single comparison operator
Evidence from the diff
The patch corrects an off-by-one logic error in ChannelManager’s manual channel acceptance path. The guard peers_without_funded_channels >= MAX_UNFUNDED_CHANNEL_PEERS was rejecting a new unfunded channel peer when the count was already equal to the maximum, whereas the limit should only trigger when the count would exceed it. The comparison is changed to >. A corresponding test loop bound is adjusted to exercise the true edge case.
Changed components
lightning/src/ln/channelmanager.rslightning/src/ln/channel_open_tests.rsInspect captured patch +2 / −2
diff --git a/lightning/src/ln/channel_open_tests.rs b/lightning/src/ln/channel_open_tests.rs
index 3a9c266..572aa0c 100644
--- a/lightning/src/ln/channel_open_tests.rs
+++ b/lightning/src/ln/channel_open_tests.rs
@@ -110,7 +110,7 @@ fn test_0conf_limiting() {
};
// First, get us up to MAX_UNFUNDED_CHANNEL_PEERS so we can test at the edge
- for _ in 0..MAX_UNFUNDED_CHANNEL_PEERS - 1 {
+ for _ in 0..MAX_UNFUNDED_CHANNEL_PEERS {
let random_pk = PublicKey::from_secret_key(
&nodes[0].node.secp_ctx,
&SecretKey::from_slice(&nodes[1].keys_manager.get_secure_random_bytes()).unwrap(),
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index 532514a..1e6dae5 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -10569,7 +10569,7 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
// If this peer already has some channels, a new channel won't increase our number of peers
// with unfunded channels, so as long as we aren't over the maximum number of unfunded
// channels per-peer we can accept channels from a peer with existing ones.
- if is_only_peer_channel && peers_without_funded_channels >= MAX_UNFUNDED_CHANNEL_PEERS {
+ if is_only_peer_channel && peers_without_funded_channels > MAX_UNFUNDED_CHANNEL_PEERS {
let send_msg_err_event = MessageSendEvent::HandleError {
node_id: channel.context().get_counterparty_node_id(),
action: msgs::ErrorAction::SendErrorMessage {
Why this scored 52/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.