You glance at your node's connection panel and something feels off. You're showing 125 active peers, which looks healthy until you sort by direction: 117 of them are inbound. Strangers knocked. Your node answered. It didn't choose a single one of those 117 peers, they chose you.

That asymmetry is not a minor footnote. It sits at the heart of how Bitcoin defends itself against one of its most persistent threats: the eclipse attack.

You Choose Outbound. The World Chooses Inbound.

Every Bitcoin Core node maintains two fundamentally different categories of peer connection. Outbound connections are ones your node dials out to establish, selecting addresses from its local peer database (the `peers.dat` file). Inbound connections arrive from the outside, from nodes that looked up your IP and knocked.

Bitcoin Core opens 10 outbound connections by default (8 full-relay, 2 block-only). It accepts up to 125 total, so the remaining 115 slots can fill with inbound peers.

When your node selects an outbound peer, it makes an active choice based on addresses gathered from multiple independent sources over time. When it accepts an inbound peer, it is, essentially, letting whoever knocked come in.

Flooding inbound slots is comparatively easy: spin up many IPs, connect aggressively, wait. Controlling outbound slots is much harder, because your node is the one dialing. An attacker who wants to isolate your node needs to control what it sees, and the inbound surface is the wide-open door.

The Eclipse Attack, Spelled Out

An eclipse attack is when an adversary surrounds a target node so completely that every connection runs through attacker-controlled peers. Once eclipsed, the victim node can be fed a false view of the blockchain: fake transaction confirmations, withheld blocks, a chain lagging behind the real tip.

Consider two node operators, Petra and Kwame. Both run nodes on residential ISPs. Kwame accepts 115 inbound connections and hasn't thought much about peer diversity. Petra runs `-maxconnections=20`, keeps most slots for outbound peers, and uses `-connect` to anchor two connections to nodes she trusts personally.

Targeting Kwame, an attacker needs to fill 115 inbound slots and crowd out his 10 outbound connections. The inbound slots are straightforward to fill from a botnet or a cloud provider with many IP addresses. The outbound slots are harder but not impossible: poison Kwame's `peers.dat` so his node dials attacker addresses on next restart.

Petra is a much worse target. Her outbound slots are partly anchored, her inbound surface is small, and any peer that misbehaves gets disconnected and penalized. The attacker would need to compromise her explicitly trusted peers, which is a different class of problem entirely.

I think the Kwame/Petra gap is larger than most node operators appreciate. Peer count is a vanity metric. Peer selection is the actual variable.

How Bitcoin Core Hardens the Outbound Path

Bitcoin Core has accumulated several specific defenses around outbound selection over its development history, most of them invisible to the average user.

Anchor connections. Since Bitcoin Core 0.20, the node saves two outbound block-relay-only peers to an `anchors.dat` file on shutdown and reconnects to them on restart. The reasoning is direct: an attacker who wants to eclipse you on reboot now has to have been your peer before the restart, not just after.

Peer bucketing. Addresses in `peers.dat` are stored in 1,024 "tried" buckets and 1,024 "new" buckets, with placement determined partly by the address's /16 IP prefix. An attacker controlling many IPs from the same subnet can't fill more than a bounded number of buckets. This scheme, formalized in research by Ethan Heilman and colleagues and then implemented in Core, makes Sybil attacks against the address database substantially more expensive. Think of it as a bouncer who counts how many people from the same neighborhood are already inside.

Feeler connections. Periodically, Bitcoin Core opens a short-lived outbound connection to a randomly selected address from the "new" table, verifies the peer is real, then disconnects. This tests addresses without committing to them and refreshes the tried table with genuinely reachable peers.

Inbound eviction. When inbound slots fill, Bitcoin Core runs a specific eviction algorithm that protects peers with low latency, high network diversity, and long connection time. A flood of new inbound connections from one subnet won't simply displace your long-standing, geographically diverse peers.

None of these mechanisms are theoretical. They're in the codebase, documented in Bitcoin Core's GitHub history and the corresponding academic literature.

The Practical Upshot for Anyone Running a Node

Your outbound connections are your lifeline to an honest view of the network. Inbound connections are a service you provide to others, fine to accept, but not what keeps you safe.

So ask yourself: do you actually know where your node is dialing?

Connection count alone is a misleading signal. A node with 100 connections, all inbound from addresses controlled by one party, is more isolated than a node with 12 connections chosen carefully across diverse network ranges. More is not always better.

The block-relay-only outbound slots also deserve attention. These peers don't relay transactions or addresses, which makes them harder for an observer to detect and map. They act as a quiet backbone for block propagation, resistant to topology-mapping attacks that rely on transaction flow analysis. Most operators ignore them. That's a mistake.

Running your node behind Tor while also maintaining a clearnet outbound connection gives you network-layer diversity that a purely clearnet or purely Tor setup doesn't. An attacker who can eclipse you on one transport still has to contend with the other.

If you know a node you trust, a friend's, a well-known public node with a long operational history, pinning one outbound connection to it with `-addnode` is a small, concrete step. Not a guarantee. A meaningful improvement over relying entirely on automated peer discovery.

Bitcoin's architecture keeps returning to the same principle: the network can't force peers to be honest, so it distributes trust across many independently chosen connections and makes any single point of capture expensive. Outbound selection is where that distribution begins. Get that wrong, and the rest of the security stack is building on sand.