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

net: increase inbound capacity for block-relay-only connections

Public commit record

What the developer wrote

Authored by Martin Zumsande

73/100 · Adequate
net: increase inbound capacity for block-relay-only connections

..and adjust the eviction logic.
The new default max connection number is 200, the default maximum of tx-relaying
inbounds is limited to 50% of all inbound connections.
With 11 outbound connections, that is (200 - 11) * 0.5 = 94.5.
As a result, the tx-related maximum traffic should not change
drastically.

When we receive an inbound connection and don't have space for another
full-relay peer, we now attempt to evict specifically a full-relay inbound
after receiving the version message of the new peer.

Once this commit is widely deployed, the added inbound capacity will
allow us to increase the number of outgoing block-relay-only connections.

Co-authored-by: Amiti Uttarwar <amiti@uttarwar.org>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This Bitcoin Core commit increases the default maximum peer connections from 125 to 200 and reserves half of inbound slots for block-relay-only peers that don't forward ordinary transactions. It also adds eviction logic so that when a new transaction-relaying inbound peer arrives and the node is at capacity, it tries to disconnect an existing transaction-relaying peer instead of a block-relay-only peer. The change is described by the authors as a network-capacity improvement, not a security fix, but it can make certain denial-of-service and eclipse-style attacks harder by diversifying peer types and limiting how many transaction-relaying inbound peers an attacker can occupy.

Recommended action

Treat as a routine network-hardening improvement. Reviewers and operators should verify that the new default connection limits and reserved full-relay percentage behave correctly under load, do not inadvertently degrade transaction propagation, and that the eviction logic does not disconnect protected peers incorrectly. No emergency deployment is warranted based on the supplied materials.

Security signals we found

01

Default network capacity increased and inbound peer composition restricted, which can reduce the relative share of attacker-controlled transaction-relay inbounds

02

New eviction logic specifically targets transaction-relaying inbound peers, making it harder for an attacker to monopolize inbound slots with full-relay connections

03

Block-relay-only inbound capacity is expanded, improving network partition resistance

04

No explicit security bug, CVE, or vulnerability description is present in the commit or supplied references

05

Change is defensive/hardening in nature rather than a patch for a known exploit

Risk score

Why this scored 29/100

Our methodology →
Potential impact 5/30
Exploitability 5/25
Stealth signal 4/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.