Peer Eviction Logic

Peer eviction logic is the routine inside Bitcoin Core — implemented as AttemptToEvictConnection() — that decides which existing inbound peer to disconnect when the node's inbound slots are full and a new peer wants in. By default a node accepts up to 125 connections; with eleven reserved for outbound use, roughly 114 inbound slots remain, and on a long-running, publicly reachable node they fill. When they do, the node faces a quiet security decision every time someone knocks: refuse all newcomers and ossify, accept randomly and become steerable, or evict intelligently. Bitcoin Core chose the third path, and the design is a small masterpiece of adversarial thinking.

Protect first, evict last

Rather than picking a victim directly, the algorithm works by protection: it walks the inbound peer list and shields small groups of peers across several independent, hard-to-forge dimensions before considering anyone for eviction. Peers with the lowest minimum ping times are protected, since network proximity is hard for a distant attacker to fake. Peers that most recently relayed novel transactions — and those that recently sent fresh blocks — are protected, because usefulness to the network is costly to counterfeit. A slice of peers is protected on netgroup diversity, keeping connections spread across unrelated network ranges, and additional slots shelter peers from alternative networks like Tor, which would otherwise lose ping-time comparisons by nature. Finally, about half of the remaining candidates are protected simply for connection longevity — loyalty, measured in uptime. Only peers left unprotected after all these passes form the eviction pool, and from that pool the node drops the youngest connection from the most heavily represented network group.

Why this shape resists abuse

Inbound slots are a finite resource, and an attacker who could reliably evict honest peers could gradually surround a victim node with connections it controls — the setup for an eclipse. The eviction logic makes that squeeze expensive by anchoring protection to qualities that cost real money or real time to fake at scale: low latency from many distinct network ranges, sustained uptime, and a track record of relaying valid blocks and transactions. An attacker spinning up thousands of cheap connections from one hosting provider shares a netgroup, has no relay history, and has no tenure — precisely the profile the algorithm evicts first. The mechanism entered Bitcoin Core as a denial-of-service mitigation and has been refined repeatedly since, including the added protections for privacy-network peers whose latency profile would otherwise disadvantage them.

One wall of a layered defense

Eviction logic guards the inbound door, but it complements — never replaces — the protections on connections your node initiates. Outbound peers are the ones an eclipse attacker most wants to own, and Bitcoin Core defends them with separate machinery: bucketed address selection, anchor connections, and dedicated block-relay-only links, covered under outbound connection slots and the broader topic of eclipse attack resistance. Together the two sides keep a node's view of the mempool and the best chain anchored to the honest network even under active connection pressure.

Why it matters for a sovereign node

If you run a reachable full node — on a homestead server, beside your miners, or on a shelf next to the router — this code is working for you constantly and invisibly. It is worth internalizing two practical lessons from it. First, accepting inbound connections is safe by design: you strengthen the network without handing strangers leverage over your node, so opening your port is a genuine public good. Second, the qualities the algorithm rewards — uptime, honest relay, diverse connectivity — are the same ones that make your own node a good citizen and a hard target. Decentralization is not an abstraction; it is thousands of independently run nodes, each quietly refusing to be surrounded.