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

server+connmgr: make outbound startup deterministic

Public commit record

What the developer wrote

Authored by Olaoluwa Osuntokun

83/100 · Strong
server+connmgr: make outbound startup deterministic

In this commit, we define TargetOutbound as the number of automatic
connections and treat explicit Connect requests as additional peers.

Permanent requests could previously consume connection IDs before Start
sampled the shared counter. The resulting automatic count depended on
goroutine scheduling, while the listener reserved the worst-case total.
We now start the configured automatic count directly and cap it by the
peer budget left after permanent peers.

The composition test covers permanent requests on both sides of Start and
pins the same automatic+permanent total for either ordering.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit fixes a scheduling bug in how a Bitcoin node decides how many automatic outbound peers to connect to at startup. Previously, if a user had configured permanent peers, those permanent peers could grab internal connection IDs before the automatic counter started, causing the node to sometimes open fewer automatic connections than intended. The patch makes the count deterministic: automatic outbound peers are always started directly, and the total is capped only after accounting for permanent peers. This is primarily a reliability/consistency fix, but inconsistent peer counts could mildly affect a node's network connectivity and resistance to eclipse attacks.

Recommended action

Treat as a low-severity reliability fix. Reviewers should verify that targetOutboundPeers correctly handles edge cases (MaxPeers <= permanentPeers, non-automatic modes) and that the new tests cover both orderings. No immediate security response is indicated unless this non-determinism is shown to be exploitable for eclipse attacks.

Security signals we found

01

Non-deterministic outbound peer count at startup

02

Permanent peers could consume connection request IDs before automatic counter sampled

03

Potential for fewer automatic outbound peers than configured, reducing network diversity

04

Fix makes peer budgeting deterministic and caps automatic peers by remaining budget after permanent peers

Risk score

Why this scored 27/100

Our methodology →
Potential impact 4/30
Exploitability 3/25
Stealth signal 5/15
Affected reach 6/15
Confidence 6/10
Evidence quality 3/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.