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

server: centralize inbound handshake admission

Public commit record

What the developer wrote

Authored by Boris Nagaev

68/100 · Adequate
server: centralize inbound handshake admission

In this commit, we introduce a server-wide admission policy for
incomplete inbound handshakes and the CPU-bound portion of v2 responder
setup. Source accounting uses normalized IPv4 and IPv6 prefixes, while
global, per-source, and concurrent v2 budgets remain independent and
bounded.

Peer construction passes the policy through a small interface only for
inbound v2 responders. Handshake slots release on verack or disconnect,
and the connection manager reserves MaxPeers capacity for automatic
outbound peers.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit adds a new inbound connection rate-limiting and admission-control system to btcd. It is designed to reduce the risk of denial-of-service attacks where an attacker opens many incomplete handshake connections or forces the server to do expensive v2 transport cryptography for many sources at once. The change caps how many unfinished handshakes a single IP prefix can hold, limits the rate of CPU-heavy v2 responder handshakes both globally and per source, and reserves part of the peer budget for automatic outbound peers so inbound connections cannot starve them.

Recommended action

Treat as a hardening/DoS-prevention patch. Review the default constants (8 pending per /24 or /64, 20 sustained/40 burst global v2, 2 sustained/4 burst per source, 4 concurrent crypto slots) against expected node load and adversarial scenarios. Ensure the v2transport replace directive and dependency changes are intentional and that downstream consumers rebuild with the updated v2transport package. Run the new admission and server lifecycle tests.

Security signals we found

01

New DoS-mitigation admission control for inbound handshakes

02

Per-source-prefix limits on incomplete handshakes

03

Rate and concurrency limits on CPU-bound v2 responder handshake cryptography

04

Source-limit bypass restricted to whitelisted and loopback addresses

05

Handshake slot released exactly once via sync.Once on verack or disconnect

06

MaxInbound connection-manager budget added to reserve outbound peer capacity

07

No CVE, advisory, or vendor security disclosure present in commit or references

Risk score

Why this scored 61/100

Our methodology →
Potential impact 18/30
Exploitability 12/25
Stealth signal 8/15
Affected reach 12/15
Confidence 7/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.