Increase no-channel peer limit
What changed, and why it matters
This commit raises the limit on how many peers without an active payment channel the software will accept connections from, from 250 to 2500. By itself this is a simple configuration tuning change, not a code fix for a specific bug. It could slightly increase resource consumption and the surface area for denial-of-service attacks, but it does not create a known exploitable vulnerability.
Treat as a routine capacity change. Review whether memory, file descriptor, and CPU budgets scale linearly with 2500 no-channel peers, and consider adding per-peer rate limits or dynamic throttling if not already present. No urgent security patch is indicated by this diff alone.
Security signals we found
Resource-limit constant increased by 10x
No validation or rate-limiting changes included
No vendor security disclosure or CVE referenced
Potential minor denial-of-service exposure through increased peer state
Evidence from the diff
The patch changes a single constant, MAX_NO_CHANNEL_PEERS, in lightning/src/ln/channelmanager.rs from 250 to 2500. This constant controls when the ChannelManager stops accepting new inbound connections from peers that do not yet have a funded channel. The change expands connection capacity but does not alter validation, authentication, rate limiting, or memory management logic. There is no accompanying security explanation or incident disclosure.
Changed components
lightning/src/ln/channelmanager.rsInspect captured patch +1 / −1
diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs
index 27765f9..318b10b 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -3317,7 +3317,7 @@ const MAX_PEER_STORAGE_SIZE: usize = 1024;
/// The maximum number of peers which we do not have a (funded) channel with. Once we reach this
/// many peers we reject new (inbound) connections.
-const MAX_NO_CHANNEL_PEERS: usize = 250;
+const MAX_NO_CHANNEL_PEERS: usize = 2500;
/// Used by [`ChannelManager::list_recent_payments`] to express the status of recent payments.
/// These include payments that have yet to find a successful path, or have unresolved HTLCs.
Why this scored 20/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.