There's no Bitcoin headquarters to call, no server you could shut down. And yet tens of thousands of Bitcoin nodes worldwide reliably find each other and continuously exchange data. How is that even supposed to work with no coordination point at all? This post shows how a single, freshly started node finds its way into the network, and how the network as a whole stays efficient regardless.
The First Contact: DNS Seeds
A node starting up for the very first time knows literally no one. As its first point of contact, Bitcoin Core uses a small, hardcoded list of eight DNS seed servers (src/kernel/chainparams.cpp), domain names like seed.bitcoin.sipa.be, run by individual, long-established Bitcoin developers (including Pieter Wuille, a Bitcoin Core co-developer since 2011, and several other independent community members). A simple name lookup against one of these seeds returns a list of currently reachable Bitcoin node addresses, comparable to a phone book with exactly one purpose: to give you the first few numbers, after that you don't need it anymore.
After That, Every Node Keeps Its Own Address Book
Once a node is connected to a few peers, it maintains its own local address book, the so-called AddrMan data structure. What's notable is the deliberate split into two separate tables: a "New" table for addresses the node has only heard about (but never successfully connected to itself), and a "Tried" table for addresses it has already connected to successfully. Each table is further split into many individual "buckets" (1,024 for "New," 256 for "Tried," set in src/addrman_impl.h), into which addresses are sorted according to a randomized scheme.
Why all this effort? It specifically makes so-called eclipse attacks harder: an attempt to completely isolate a single node by surrounding it exclusively with addresses the attacker controls. An attacker would have to simultaneously dominate large portions of both separate tables, which considerably raises the cost compared to a single, simple address list.
How a Message Even Gets Recognized as a "Real Bitcoin Message"
Every message sent between two Bitcoin nodes starts with four very specific bytes, the so-called "magic bytes" (on mainnet, exactly 0xf9 0xbe 0xb4 0xd9, set in src/kernel/chainparams.cpp). These four bytes serve exactly one purpose: making sure messages from the test network (testnet) or another experimental network never accidentally end up on the real, production Bitcoin network (mainnet). If the correct magic bytes are missing at the start, a node discards the message immediately, without processing it any further.
After that comes a brief handshake: two newly connected nodes first exchange version messages (among other things: which protocol version am I speaking, which features do I support, what time is it for me, how high is my current block count) and confirm this to each other with a short verack message. Only after that does the actual exchange of transactions and blocks begin.
Deliberately Few Connections of Your Own
A single node holds a maximum of 125 simultaneous connections by default (DEFAULT_MAX_PEER_CONNECTIONS in src/net.h), but of those, at most eight are self-initiated, full-fledged outbound connections (MAX_OUTBOUND_FULL_RELAY_CONNECTIONS). The rest of the slots are reserved for incoming connections from other nodes, plus a handful of specialized connection types (such as pure "block-only" connections without transaction relay, or brief "feeler" connections that only test whether an address is still reachable at all).
This deliberately low number of actively chosen connections is a trade-off: more connections would make attacks like the eclipsing mentioned above harder to pull off, but they also cost more bandwidth and system resources, and with thousands of nodes worldwide, uncontrolled network growth would quickly become inefficient.
Why No One Gets "More Votes" Just by Running More Nodes
A common misconception is worth clearing up here: someone running ten of their own Bitcoin nodes at once does NOT thereby get ten times the influence over the network, unlike the mining computing power described in Part 2 above, which genuinely does count. A node merely checks whether transactions and blocks follow the known rules, and relays them, it doesn't "vote" on anything. The concept of a so-called Sybil attack (named after a well-known case study of multiple personalities, where a single entity poses as many different ones) goes nowhere in Bitcoin, because simply running a node gives you nothing you could "vote" on through sheer numbers. The only thing that actually counts is computing power in the mining process (Part 2), and that can't be multiplied by starting additional software instances, only through real, physical hardware and real electricity consumption.
Nodes Can Still Hide: Tor Support
Anyone who runs their own node but doesn't want their internet provider or curious observers on the network to see that their household in particular just sent a specific Bitcoin transaction can run their node over the Tor anonymity network (built into the code as a well-supported, dedicated mode, src/torcontrol.h and others). The node is then only reachable via a Tor "onion" address, instead of its otherwise easily identifiable IP address. Interestingly, from the rest of the network's perspective, such a node behaves completely normally, it follows exactly the same rules, sends and receives the same messages, just via an extra anonymizing detour.
Efficient Block Relay: Compact Blocks
A newly found block often contains hundreds or thousands of transactions, but a receiving node already knows most of them from its own mempool anyway, since they traveled through the network via exactly the same route beforehand. The so-called Compact Blocks technique (officially BIP152) exploits this: instead of transmitting the complete block, a node in "high-bandwidth" mode sends up to three preferred neighboring nodes at once only a very compact version with short transaction identifiers. The recipient reconstructs the full block largely from its own mempool and only specifically requests the few transactions it genuinely doesn't already know. This saves considerable bandwidth and speeds up how quickly a new block propagates across the entire network, which matters because slow propagation increases the risk of briefly competing chains.
A Trip Through a New Node's First Few Seconds
To see it all in context once more, here's the complete sequence a node runs through in its very first seconds: it starts with zero knowledge of the network, queries the eight hardcoded DNS seeds for initial addresses, tries in parallel to establish a real connection to a handful of them, exchanges the version/verack handshake with every successful connection, during which both sides also announce which additional services they offer (for example, whether they hold the complete blockchain history or only a recent slice of it). The new node then politely asks its fresh neighbors for further addresses they know about (via a getaddr message), stores the responses in its own, still-empty AddrMan table, and starts connecting to more of these newly learned addresses until it reaches its eight outbound connections. Only after that does the actual download of the missing blockchain history, or the ongoing receipt of new blocks and transactions, begin. All of this typically happens within a few seconds of the program starting, entirely automatically, without the operator having to configure anything.
Deliberate Delay as a Privacy Tool
A particularly unremarkable but clever detail in the code concerns exactly WHEN a node relays a new transaction or a new address to its neighbors. You might assume "immediately" is the obvious answer: fast relaying sounds like good network behavior at first glance. But that would create exactly a security problem: an observer connected to many nodes on the network at once could, purely from WHO sends out a given transaction first, fairly reliably infer which node (and therefore potentially which real internet connection) it originally came from.
Bitcoin Core counters this with deliberately built-in, randomized delay: both new address information (on average every 30 seconds per neighbor connection, but with a randomly varying exact timing, governed by a so-called exponential distribution) and new transaction announcements aren't relayed immediately, but after a short, randomly rolled waiting period, with inbound connections even getting their own additional random delay per individual connection. The effect: an attacker trying to reconstruct a transaction's origin purely through timing measurements sees a noticeably blurrier picture through this artificial "noise" than they would without this delay. A nice example of how privacy in Bitcoin isn't only a matter of cryptography, sometimes it's implemented quite pragmatically with a few lines of timing logic.
What This Means for Bitcoin's Overall Resilience
The practical consequence of all these individual decisions is remarkably robust: because there's no central server, there's also no single point of attack whose shutdown could cripple the network. Even if all eight DNS seeds failed simultaneously, already-running nodes could keep communicating with each other without any trouble, via their own, already-populated AddrMan tables and via already-known node addresses entered directly by users, the seeds only matter for the very first entry point, not for ongoing operation. This redundancy at every level (many independent seeds, many independent connections per node, no central coordination point) is the real reason Bitcoin has stayed reachable continuously since its launch, without a single notable network-wide outage.
Conclusion: Order Without a Center
From the first DNS query, through its own attack-resistant address book, to the clever Compact Blocks trick, the network layer is a textbook example of how Bitcoin manages to work reliably and efficiently without any central coordination point at all: through a combination of a few fixed starting points and countless small, local decisions each node makes for itself.
Next up, Part 6: Your Wallet From the Inside, how it selects funds and builds payments.
