Anchor Connection

Anchor connection is a peer that a Bitcoin Core node deliberately tries to reconnect to first when it restarts. On clean shutdown, the node writes its current outbound block-relay-only peers to a small file named anchors.dat in its data directory. On the next startup, before reaching out to any new or randomly selected peers, the node attempts to re-establish links with these saved anchors. It is a tiny mechanism — a file, a couple of peers, a preference at boot — but it closes one of the most practical attack windows against a self-hosted node.

The restart-based eclipse problem

To eclipse a node is to surround it entirely with attacker-controlled peers, so that everything it learns about the network — blocks, transactions, fee conditions — is filtered through the adversary. Eclipsing a long-running node is hard, because its connection slots are already occupied by honest peers. The pragmatic attack is therefore to force or simply wait for a restart, then race to fill every one of the node's outbound slots with malicious peers before it can rediscover honest ones. Reboots happen constantly in the real world: power cuts, OS updates, hardware swaps, a home server tripping a breaker. Each one used to hand an attacker a clean slate. Anchors close that window: by reconnecting first to peers it was already using before the restart, the node carries at least some honest links across the reboot, and the attacker never gets the blank slate the attack depends on.

Why block-relay-only peers are chosen

Anchors are drawn specifically from the node's block-relay-only connections rather than its full-relay peers, and the choice is deliberate. Block-relay-only links carry blocks and headers but do not gossip transactions or addresses, which makes them far harder for a network observer to map: your node never advertises which peers those are. An attacker who cannot identify your anchors cannot pre-position itself to impersonate them or attack them ahead of your restart. The block-relay-only design and the anchor mechanism were introduced as complementary hardening — quiet connections that are both hard to discover and sticky across reboots.

What it means for a node runner

The best part for a sovereign operator: anchors require zero configuration. If you run Bitcoin Core — whether an archival full node or a disk-friendly pruned node on a small home server — the mechanism works silently. There are only two things worth knowing. First, anchors.dat is written on clean shutdown; a hard power loss may skip it, which is one more small argument for shutting your node down properly rather than pulling the plug. Second, the file is consumed at startup and rewritten at the next shutdown, so a node that keeps crashing before writing it loses the protection — a subtle reason to investigate instability rather than tolerate it.

Part of a layered defense

Anchors are one layer in a stack of eclipse countermeasures that includes diversified peer selection across network groups, protected peer slots, and feeler connections that continuously test the address book. No single layer is decisive; together they make eclipsing a patched, well-connected node genuinely expensive. Anchors are also the best kind of hardening: free, automatic, with no flags to set and nothing to maintain. For the broader picture of how these mechanisms interlock — and why an eclipsed node is dangerous even if you are not a miner — see eclipse-attack resistance. And if you mine, the stakes are higher still: an eclipsed miner can be fed a stale chain view and waste real hashrate on blocks the honest network will never accept. The node you validate with is infrastructure; anchors are one of the reasons it stays your infrastructure across every reboot.