Bootstrap Node

What Is a Bootstrap Node?

A bootstrap node is a well-known network entry point that new clients connect to when they have no prior knowledge of other peers. In Bitcoin, bootstrap nodes take two forms: DNS seeds (domain names that return lists of active node IP addresses) and hardcoded seed nodes (IP addresses compiled directly into the Bitcoin Core binary as a fallback).

Every peer-to-peer network faces a chicken-and-egg problem: to join the network, you need to know at least one existing participant, but you cannot learn about participants without being on the network. Bootstrap nodes break this cycle by serving as publicly known entry points. They do not have special privileges or authority over the network; their only role is to introduce new nodes to other peers so that normal peer discovery can begin.

Once a node has connected to the network and populated its local peer database, it rarely needs bootstrap nodes again. On subsequent startups, it reconnects to peers it already knows from previous sessions.

How It Works

When a fresh Bitcoin Core node starts with an empty peer database (peers.dat), it goes through a multi-stage discovery process:

1. Check the local peers.dat file for previously known peers (empty on first run)
2. Query DNS seed domains to obtain IP addresses of active nodes
3. If DNS seeds fail to respond within 60 seconds, fall back to hardcoded seed node IP addresses compiled into the binary
4. Initiate TCP connections to discovered peers and perform the version handshake: exchange version messages (protocol version, block height, timestamp), then confirm with verack
5. Send getaddr messages to connected peers requesting their known addresses
6. Receive addr messages containing other reachable nodes on the network
7. Persist discovered addresses to peers.dat for future startups

After this initial discovery phase, the node transitions to standard gossip-based peer management. It periodically exchanges address messages with its peers, continuously refreshing its view of the network without any further reliance on bootstrap infrastructure.

DNS Seeds

DNS seeds are the primary bootstrap mechanism in Bitcoin Core. Each seed is a domain name operated by a trusted community member who runs crawler software that continuously scans the Bitcoin network for reachable nodes. When a new node queries these domains via standard DNS resolution, the response contains IP addresses of recently active nodes.

The current mainnet DNS seeds in Bitcoin Core include domains operated by well-known contributors:

// From Bitcoin Core's chainparams.cpp
vSeeds.emplace_back("dnsseed.bluematt.me");
vSeeds.emplace_back("seed.bitcoin.jonasschnelli.ch");
vSeeds.emplace_back("seed.btc.petertodd.net");
vSeeds.emplace_back("seed.bitcoin.sprovoost.nl");
vSeeds.emplace_back("dnsseed.emzy.de");
vSeeds.emplace_back("seed.bitcoin.wiz.biz");
vSeeds.emplace_back("seed.mainnet.achownodes.xyz");

DNS seed operators must follow a formal policy documented in Bitcoin Core's repository. Key requirements include: serving only fairly selected, functioning Bitcoin nodes; enforcing a DNS TTL of less than one minute to keep results fresh; following good host security practices; and minimizing query logging with no disclosure to third parties.

Hardcoded Seed Nodes

If DNS resolution fails (due to network restrictions, censorship, or DNS infrastructure issues), Bitcoin Core falls back to a list of hardcoded IP addresses compiled into the binary. These addresses, stored in the vFixedSeeds array, represent nodes that were active on the network at the time the software version was released.

Hardcoded seeds are a last-resort mechanism. Because they are static and only updated with new software releases, some addresses may have gone offline since compilation. However, they provide a censorship-resistant fallback that does not depend on DNS infrastructure.

Manual Configuration

Bitcoin Core provides three command-line flags for users who want to control their bootstrap process manually:

# Connect to a node, fetch addresses, then disconnect
# Similar to a DNS seed but using a specific IP
bitcoind -seednode=192.168.1.100:8333

# Maintain a persistent connection to a specific node
# while also discovering peers normally
bitcoind -addnode=192.168.1.100:8333

# Connect ONLY to specified nodes
# Disables all other peer discovery
bitcoind -connect=192.168.1.100:8333

The -seednode flag mirrors DNS seed behavior: connect, learn addresses, disconnect. The -addnode flag keeps a persistent connection to the specified peer while also discovering others normally. The -connect flag is the most restrictive: it disables DNS seeds, hardcoded seeds, and address gossip entirely, limiting the node to only the specified peers.

All three flags accept multiple values, allowing operators to specify several bootstrap or persistent peers.

Why It Matters

Bootstrap nodes are a critical piece of network infrastructure that most users never think about. They enable the permissionless nature of Bitcoin: anyone can download the software, start a node, and join the network without requesting access from any authority. The bootstrap process happens automatically and transparently in the background.

For node operators running Bitcoin Core behind restrictive firewalls or in censored network environments, understanding bootstrap mechanisms is essential. The -connect flag allows operators to tunnel through specific trusted peers, while the hardcoded seed fallback ensures connectivity even when DNS is blocked.

The design also illustrates a recurring theme in decentralized systems: some degree of initial trust is unavoidable. A brand-new node must trust that at least some bootstrap nodes will connect it to the real Bitcoin network rather than an attacker-controlled fake. Bitcoin mitigates this risk through redundancy (multiple independent DNS seed operators), block header verification (checking proof-of-work from the genesis block), and the diversity of hardcoded fallback addresses.

Use Cases

• First-time node setup: a user downloads Bitcoin Core and starts it for the first time. DNS seeds automatically provide an initial set of peers, and the node begins its initial block download within seconds.
• Pruned or resource-constrained nodes: lightweight setups that frequently restart benefit from fast re-bootstrapping when their peer database becomes stale. DNS seeds quickly refresh the peer list with currently active nodes.
• Private or enterprise deployments: organizations running Bitcoin infrastructure can use -connect to ensure their nodes only communicate with known, controlled peers, bypassing the public bootstrap process entirely.
• Censorship circumvention: in regions where DNS is filtered, the hardcoded seed node fallback provides an alternative path to network discovery that does not rely on domain name resolution.
• Testing environments: developers working on signet or regtest use -seednode or -addnode to connect test nodes to each other without configuring DNS seeds.

Risks and Considerations

Eclipse Attacks

An eclipse attack occurs when an adversary controls all of a victim node's peer connections, isolating it from the honest network. If an attacker compromises multiple DNS seed operators or poisons DNS responses, a new node could be fed exclusively malicious peer addresses during bootstrapping.

Bitcoin Core mitigates this through multiple independent DNS seeds operated by different community members, geographic and network diversity in seed selection, and proof-of-work validation that makes it computationally infeasible to fool a node with a fake chain for long.

Privacy Implications

DNS queries are typically unencrypted, meaning ISPs and network observers can see that a user is bootstrapping a Bitcoin node. The DNS seed operator also learns the IP address of the querying node. While the privacy landscape continues to evolve, users concerned about metadata leakage can use Tor or manually configure peers with -connect to avoid DNS queries entirely.

BIP 324 (v2 transport protocol), enabled by default since Bitcoin Core v27.0, adds opportunistic encryption to peer-to-peer connections. While it does not change the bootstrap mechanism itself, it protects traffic after the initial connection from passive eavesdropping.

Centralization Pressure

The bootstrap process introduces a mild centralization vector: the set of DNS seed operators is small and curated. If several operators were compromised simultaneously, the consequences for newly connecting nodes could be significant. The Bitcoin Core project addresses this by maintaining strict operator policies, requiring multiple independent operators across different jurisdictions, and providing the hardcoded fallback list as a secondary path.

Stale Seeds

Hardcoded seed addresses in vFixedSeeds become stale over time as nodes go offline. A node that cannot reach DNS seeds and must rely solely on hardcoded addresses may struggle to find active peers if the binary is old. Keeping Bitcoin Core updated ensures the hardcoded list remains reasonably current.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.