Eclipse-Attack Resistance

Eclipse-attack resistance is the collection of design choices in Bitcoin Core that make it hard for an attacker to eclipse a node — that is, to monopolize all of its connections so the victim sees only attacker-controlled peers and a false view of the network. An eclipsed node can be fed a stale or fake chain, tricked into accepting double-spends, or split off to weaken the honest network. Hardening against this is not one feature but a layered set of defenses that work together.

The layered defenses

The first layer is the Address Manager (addrman), whose "new"/"tried" tables and source-group bucketing make it expensive to flood a node with attacker addresses. On top of that sit hidden, hard-to-target links: block-relay-only connections that exchange blocks without gossiping the node's transactions or address, and anchor connections that reconnect to trusted block-relay peers first on restart so an attacker cannot exploit the reboot window. Feeler connections keep the tried table populated with genuinely reachable honest peers, and careful peer-eviction logic protects a diverse, hard-to-forge set of inbound peers when slots fill.

Why no single fix suffices

An eclipse attack succeeds only if the attacker controls every one of a node's peers, so resistance is about denying an attacker reliable control of any connection class. Diversifying outbound peers across network groups, fixing the number of outbound slots, preferring addresses from many distinct source networks, and connecting over Tor/I2P all raise the cost. For a sovereign operator the takeaway is simple: a default Bitcoin Core node already implements strong eclipse resistance automatically, and running over multiple network transports strengthens it further.

These mechanisms collectively counter the broader eclipse attack; the addrman bucketing at their core is detailed under Address Manager (addrman).