Address Manager (addrman)

The Address Manager, known in the Bitcoin Core source as addrman, is the in-memory database every full node uses to track the IP addresses of other nodes it has learned about. It is persisted to peers.dat so that a node can quickly rebuild its peer connections after a restart instead of starting from the DNS seeds each time. For a sovereign Bitcoiner running a node at home, addrman is the quiet machinery that decides who your node talks to.

The new and tried tables

addrman is split into two tables. The new table holds addresses your node has heard about via gossiped addr messages but has not yet successfully connected to; it spans 1024 buckets. The tried table holds addresses your node has actually connected to and verified as reachable; it spans 256 buckets. An address is placed into a bucket using a cryptographic hash of the source peer's network group and the destination address, which is the heart of addrman's security model.

Why bucketing matters

The bucketing scheme exists to make it expensive for an attacker to flood your address table with their own malicious nodes. Because bucket placement depends on the attacker's network group (their autonomous system or /16 range), poisoning the table meaningfully would require controlling addresses across many distinct networks rather than a single cheap subnet. This randomized bucketing is a core defense against the kind of address poisoning that precedes a full network isolation.

addrman feeds the node's outbound peer selection, so a healthy, diverse address table is foundational to staying connected to the honest network. See related entries on the feeler connection that refreshes the tried table and on eclipse-attack resistance.

The Lifecycle of an Address

An address's journey through addrman is deliberately slow and skeptical. It arrives via gossip — an addr message from a peer, who may be honest or hostile — and lands in the new table, recorded alongside which peer told us about it. It graduates to tried only when the node itself completes a successful connection; hearsay never earns trust directly. Each bucket holds a limited number of slots, and when a placement collides with an existing entry, the node applies eviction logic — testing whether the incumbent is still reachable before deciding which to keep — rather than letting newcomers freely displace proven peers. The result is a table where an attacker's fabricated addresses must fight for space against addresses your node has personally verified.

Feelers: Quiet Verification in the Background

Nodes maintain the table's honesty with feeler connections — short-lived, occasional connections whose only purpose is to test whether a candidate address actually answers. A successful feeler promotes an address toward the tried table; a failure is evidence for eviction decisions. Feelers cost almost nothing (they open, complete a handshake, and close) but continuously convert the new table's rumors into verified knowledge, which keeps the tried table fresh even when the node's eight or so outbound slots are stable for weeks. It is a small mechanism with an outsized role: it denies attackers the strategy of filling the table with plausible-looking dead addresses.

Why a Home Node Operator Should Care

Addrman is your node's memory of the honest network, and its diversity is a security property you can influence. A node whose table spans many network groups — different providers, different regions, and ideally multiple transports such as clearnet plus Tor — is materially harder to eclipse than one that learned everything from a single neighborhood of the internet. Practical hygiene: let peers.dat persist across restarts rather than deleting it (a node with an empty table must bootstrap from DNS seeds, its most influenceable moment), and be suspicious of advice to “fix” connectivity by wiping peer state. For the attack this whole design frustrates, see eclipse-attack resistance.