AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Moderate 54 Bitcoin

Add optional rate-limit on incoming pre-auth connections (#3356)

Public commit record

What the developer wrote

Authored by Bastien Teinturier

86/100 · Strong
Add optional rate-limit on incoming pre-auth connections (#3356)

Peers that open a connection but never complete the BOLT 8 handshake
consume resources on our node (memory, file descriptors and CPU).

We now bound how many of those we're willing to keep around, with an
eviction mechanism that lets honest peers eventually get connected.

Note that this only affects incoming connections: outgoing connections
are not rate-limited, which means that peers with whom we have channels
cannot be negatively affected by this mechanism since we'll actively
reconnect to them.

This isn't a foolproof DDoS protection at all however: attackers that
spam connection attempts can still severely delay or prevent honest
new peers from connecting. It should be coupled with a DDoS protection
layer at the cloud provider layer, where it is easier to do correctly
and more efficient.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit adds a safety net to the Eclair Lightning node to limit how many incoming peer connections can sit unfinished before completing the cryptographic handshake. Previously, an attacker could open many TCP connections and leave them hanging, consuming memory, file descriptors, and CPU. The change caps those pending connections, evicts the oldest ones after a short grace period, and briefly pauses accepting new connections when the cap is hit. It also fixes a related bug where authenticated-but-never-initialized connections could stay open forever.

Recommended action

Operators should review the new defaults (500 pending, 1 s min age, 100 ms accept delay) and tune them to their node's capacity and threat model. Because the commit itself notes this is not a full DDoS defense, it should be combined with network-layer rate limiting at the firewall, load balancer, or cloud provider. Upgrade to include this patch if running a public Eclair node.

Security signals we found

01

Resource-exhaustion mitigation: bounds unauthenticated incoming connections to prevent memory/file-descriptor/CPU exhaustion

02

New kill reason TooManyPendingConnections added to PeerConnection.KillReason

03

New metrics incomingconnections.pending/evicted/rejected for monitoring abuse

04

Fix for previously unbounded authenticated-but-uninitialized connections staying alive forever

05

Release notes explicitly describe the change as a last-resort safety net, not a full DDoS solution

Risk score

Why this scored 54/100

Our methodology →
Potential impact 12/30
Exploitability 10/25
Stealth signal 8/15
Affected reach 12/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.