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

server+inbound: correct inbound admission accounting

Public commit record

What the developer wrote

Authored by Olaoluwa Osuntokun

73/100 · Adequate
server+inbound: correct inbound admission accounting

In this commit, we keep loopback and whitelisted peers inside the ordinary
pending-handshake and V2 source budgets, while preserving their existing
no-ban behavior.

We also derive the listener reservation from the configured peer mode.
Connect-only and simnet nodes now reserve just their permanent peers, while
automatic mode accounts for both its target and addpeers without exceeding
MaxPeers.

Finally, a bound V2 handshake consumes its rate budgets once, but reacquires
the concurrency slot for each CPU-bound responder phase. This keeps rate
limiting scoped to the handshake while bounding both expensive phases.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes accounting bugs in how btcd counts and limits incoming peer connections. Previously, loopback/whitelisted peers and permanent outbound peers (such as manually added peers) were not correctly counted against connection budgets, which could let a node accept more inbound connections than intended or let special peers bypass per-source rate limits. The patch makes the counts consistent so the configured maximum peer limits are actually enforced for all peer types, while still preserving the existing rule that whitelisted/loopback peers cannot be banned.

Recommended action

Treat as a hardening/resource-integrity fix. Review deployment configs that rely on loopback/whitelisted peers bypassing source limits, because those peers now consume ordinary budgets. Ensure MaxPeers values account for permanent/addpeer reservations in connect-only and simnet modes. No immediate emergency response is indicated, but operators should validate listener capacity after upgrade.

Security signals we found

01

Resource-limit accounting correction for inbound peer admission

02

Per-source rate limits now apply to loopback and whitelisted peers

03

MaxPeers reservation now includes permanent/addpeer outbound slots

04

V2 handshake rate tokens consumed once, concurrency slots per CPU phase

05

No security relevance disclosed by vendor in commit message or title

Risk score

Why this scored 48/100

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