How the Bitcoin Network Works
Bitcoin is, at its core, a peer-to-peer network protocol. Before it is a currency or a ledger, it is a distributed system that must solve the same problems every large-scale network faces: node discovery, message propagation, topology resilience, and resistance to adversarial actors. The Bitcoin network runs on top of the same internet infrastructure that BGP routes and autonomous systems organize, and its design reflects hard-won lessons about operating in an environment where you cannot trust your peers.
This article dissects the Bitcoin network layer — not the blockchain data structures or consensus rules, but the networking protocol that makes it all work. We will cover how nodes find each other, how blocks and transactions propagate, how the network topology has evolved, and the ongoing research efforts to make Bitcoin's network layer faster, more private, and harder to attack.
The Bitcoin P2P Protocol
Bitcoin nodes communicate using a custom binary protocol over TCP, typically on port 8333 for mainnet. The protocol is message-based: each message has a 24-byte header containing a magic number (to identify the network), a command name, a payload length, and a checksum. The magic bytes for mainnet are 0xF9BEB4D9, and they serve the same purpose as BGP's marker field — identifying legitimate protocol traffic.
When two nodes connect, they perform a version handshake. The initiating node sends a version message containing its protocol version, the services it supports (full node, bloom filters, witness data, compact filters), its best block height, and its local timestamp. The receiving node responds with its own version message, and both sides send a verack to confirm. This is analogous to the BGP OPEN message exchange that establishes a session between two routers.
After the handshake, nodes exchange inventory. The key message types are:
inv— "I have these items" — announces the hashes of transactions or blocks the node knows aboutgetdata— "Send me these items" — requests the full data for specific hashestx— a full transactionblock— a full blockheaders— block headers only, used during initial syncaddr/addrv2— network addresses of other known nodes
Node Discovery: Finding Peers
A new Bitcoin node needs to find other nodes to connect to. Bitcoin uses a layered approach to peer discovery, similar in spirit to how BGP routers need configured neighbors but with more automation.
DNS Seeds
The primary bootstrap mechanism is DNS seeds — hardcoded domain names that resolve to IP addresses of known reliable nodes. Bitcoin Core ships with approximately ten DNS seeds run by well-known community members. When a node starts for the first time, it queries these seeds via standard DNS A and AAAA records. Each seed returns a set of IPv4 and IPv6 addresses of nodes that were recently seen as reachable. This is a one-time bootstrap — once a node has peers, it learns about additional nodes through the gossip protocol.
The DNS seeds themselves are specialized crawlers that continuously probe the Bitcoin network, maintain a database of reachable nodes, and serve a rotating subset via DNS. They run custom software like bitcoin-seeder and typically filter for nodes that support current protocol versions and have been up for at least a few hours.
The addr / addrv2 Gossip Protocol
Once connected, nodes exchange peer addresses using the addr (and the newer addrv2, BIP 155) messages. Each node maintains a database of known peer addresses — called the addrman (address manager) — and periodically forwards a subset of addresses to its neighbors. The address manager uses a sophisticated bucketing system with two tables:
- New table — addresses the node has heard about from other peers but hasn't connected to yet, organized into 1,024 buckets
- Tried table — addresses the node has successfully connected to in the past, organized into 256 buckets
The bucketing is keyed by the source of the address and the address's IP group (roughly corresponding to /16 for IPv4), which is a deliberate defense against eclipse attacks — more on those later. The addrv2 message, introduced in Bitcoin Core 22.0, extends the original addr format to support variable-length addresses, enabling Tor v3 (.onion), I2P (.b32.i2p), and CJDNS addresses alongside traditional IPv4 and IPv6.
Hardcoded Seeds
As a fallback of last resort, Bitcoin Core contains a hardcoded list of node IP addresses compiled at release time. These are used only if DNS seed queries fail — for example, if DNS is censored or unavailable. This list is rarely needed in practice.
Block Relay: Getting Blocks Fast
Block propagation speed is critical for Bitcoin's security. The faster a new block reaches all nodes, the lower the risk of accidental chain forks (where two miners find blocks nearly simultaneously). Slow propagation also gives large miners an advantage — they learn about their own blocks instantly while other miners waste work on stale blocks.
Legacy Block Relay
In Bitcoin's original design, block relay worked through the inv/getdata/block message sequence. A node that receives or mines a new block sends an inv message to all its peers, each peer responds with getdata, and the node sends the full block. A typical block is 1-2 MB, and with 8-10 peers, the originating node had to upload the full block many times. This was slow — block propagation across the network could take 10+ seconds.
Compact Blocks (BIP 152)
Compact block relay, specified in BIP 152 and deployed in Bitcoin Core 0.13.1 (2016), dramatically reduced block propagation time. The insight is that by the time a block is mined, most of the transactions it contains are already in every node's mempool. Instead of sending the full block, the mining node sends a compact block containing:
- The block header (80 bytes)
- Shortened transaction IDs (6 bytes each instead of 32) for every transaction in the block
- A few "prefilled" transactions (like the coinbase) that the receiver definitely doesn't have
The receiving node matches the short IDs against its mempool and can typically reconstruct the entire block without requesting any additional data. If some transactions are missing (a "reconstruction failure"), the node requests just those specific transactions via a getblocktxn message. In practice, compact blocks reduce bandwidth by 90-99% and cut propagation latency to under a second for well-connected nodes.
BIP 152 defines two modes:
- Low-bandwidth mode — the sender first sends a compact block announcement, and the receiver opts in by requesting it. This is the default for most peers.
- High-bandwidth mode — the sender pushes compact blocks immediately without waiting for a request. A node selects up to three peers for high-bandwidth mode — typically the peers that have been fastest at relaying recent blocks.
Transaction Propagation and the Mempool
When a user broadcasts a transaction, it enters the mempool (memory pool) — each node's local set of unconfirmed transactions waiting to be included in a block. Transaction propagation is a gossip process: the broadcasting node sends an inv message to its peers, peers that don't have the transaction request it with getdata, and the originator sends the full tx message. The transaction then ripples outward through the network.
Each node independently validates every transaction it receives against a set of consensus and policy rules before accepting it into its mempool and relaying it further. This includes verifying digital signatures, checking that inputs are unspent, and ensuring the transaction pays a sufficient fee. The policy rules are more restrictive than consensus rules — a node might reject a transaction that is technically valid but considered non-standard (unusual script types, excessive size, etc.). This is the mempool's role as a DoS filter: by enforcing fee minimums and size limits, nodes avoid relaying spam transactions that would waste network bandwidth.
Mempool Policies
Key mempool policies that shape transaction propagation:
- Minimum relay fee — transactions below 1 sat/vbyte are typically not relayed. Nodes can configure their own minimum.
- Maximum mempool size — default is 300 MB. When the mempool is full, the lowest-feerate transactions are evicted to make room.
- Replace-by-fee (RBF) — BIP 125 allows a transaction to be replaced by a higher-fee version, with rules to prevent DoS (the replacement must pay more total fees and increase the feerate).
- CPFP (Child-Pays-for-Parent) — miners consider chains of transactions together, so a high-fee child transaction can "pull" a low-fee parent into a block.
- Package relay — a more recent development (BIP 331) that allows nodes to evaluate groups of related transactions together for relay, improving the reliability of CPFP and other multi-transaction constructs.
Network Topology
The Bitcoin network is not a flat, uniform mesh. It is a heterogeneous collection of different node types with very different roles, resource requirements, and connectivity patterns.
Full Nodes
A full node downloads and validates every block and every transaction against the consensus rules. It maintains a complete copy of the UTXO set (the set of all unspent transaction outputs) and can independently verify that any new transaction or block is valid without trusting anyone else. As of 2025, there are roughly 18,000 reachable full nodes on the network (and likely a similar number of unreachable nodes behind NAT or firewalls).
Full nodes typically maintain 8 outbound connections (peers the node chose to connect to) and accept up to 125 inbound connections (peers that connected to the node). The distinction matters for security: outbound connections are harder for an attacker to control because the node selects them using its own address manager.
SPV and Light Clients
Simplified Payment Verification (SPV) clients, described in Satoshi Nakamoto's original whitepaper, download only block headers (80 bytes each, versus megabytes for full blocks) and use Merkle proofs to verify that a specific transaction is included in a block. SPV clients trust that the longest chain is valid — they cannot independently verify consensus rules. Modern light clients use compact block filters (BIP 157/158, also called Neutrino) instead of the older bloom filter approach (BIP 37), which had serious privacy leaks.
Mining Pools
Mining pools are a dominant feature of Bitcoin's network topology. Rather than solo mining, individual miners (or ASIC operators) connect to a pool server, which coordinates work assignment and distributes rewards. The pool's node is the one that actually constructs blocks and communicates with the Bitcoin P2P network. From the network's perspective, a mining pool with thousands of hardware miners appears as a single, very well-connected node.
The major pools — Foundry USA, AntPool, F2Pool, ViaBTC, Binance Pool — collectively control the vast majority of hash rate. Their nodes are typically run on high-bandwidth connections with careful peering, because even a few hundred milliseconds of block propagation delay can cost tens of thousands of dollars in orphaned blocks.
The FIBRE Relay Network
FIBRE (Fast Internet Bitcoin Relay Engine) was a purpose-built network for ultra-fast block relay between miners and major nodes. Created by Matt Corallo in 2016, FIBRE used a combination of UDP-based transport, forward error correction (FEC) codes, and strategically placed relay nodes on dedicated network paths to achieve block propagation times of under 100 milliseconds globally — an order of magnitude faster than the regular P2P network.
FIBRE worked by pre-positioning encoded block data at relay nodes. When a new block was found, the relay nodes had already cached transaction data from their mempools and could reconstruct and forward blocks with minimal additional data transfer. The FEC codes meant that blocks could be reconstructed even if some UDP packets were lost in transit, avoiding the latency penalty of TCP retransmissions.
FIBRE was effectively retired around 2020 as compact blocks (BIP 152) closed most of the performance gap within the standard P2P protocol. However, its design influenced subsequent work on block relay optimization, and some mining operations still run private relay networks based on similar principles.
Erlay: Efficient Transaction Relay (BIP 330)
Erlay (BIP 330) is a protocol improvement that reduces the bandwidth consumed by transaction relay. In the current protocol, every node sends a transaction announcement (inv) to every peer, leading to massive redundancy — a typical transaction is announced to the same node multiple times from different peers. Studies show that transaction announcements account for approximately 40-50% of a Bitcoin node's total bandwidth.
Erlay replaces this flood-based announcement with a hybrid approach:
- Direct relay to a small number of peers (typically 8 outbound) — the node sends
invmessages to a limited set of peers, just as today - Set reconciliation with all other peers — periodically, the node and each peer exchange a compact sketch (using the Minisketch library, based on PinSketch set reconciliation) of their recent transaction sets, and efficiently determine which transactions the other is missing
The sketch-based reconciliation is remarkably efficient: two nodes can determine the symmetric difference of their transaction sets using a data structure that scales with the number of differences, not the total set size. If two nodes differ by 5 transactions out of 10,000 in their mempools, the sketch might be only a few hundred bytes.
Erlay's projected impact is a ~40% reduction in overall bandwidth for a typical full node. More importantly, it makes it practical to increase the default number of outbound connections from 8 to 12 or more without proportionally increasing bandwidth, which improves the network's connectivity and resilience against partition attacks. Erlay has been under development since 2019 and implementation is progressing in Bitcoin Core.
Privacy on the Network: Tor and I2P
Bitcoin transactions are pseudonymous on the blockchain, but the network layer can leak identity. When a node broadcasts a transaction, the originating IP address is visible to its peers. A well-positioned adversary — an ISP, a state actor, or even a set of spy nodes — can use timing analysis and network topology to trace a transaction back to its origin. This is where Bitcoin's integration with privacy networks becomes critical.
Tor Support
Bitcoin Core has supported connections over Tor since 2012. When running with Tor, a Bitcoin node creates a .onion hidden service and accepts connections through the Tor network. All traffic is encrypted and routed through multiple relays, hiding both the node's IP address and its physical location. Since the introduction of addrv2 (BIP 155), Tor v3 addresses (56 characters) are natively supported in the address gossip protocol.
Running Bitcoin over Tor provides several benefits:
- IP address privacy — peers and spy nodes cannot learn your real IP address
- Censorship resistance — in jurisdictions where Bitcoin is banned, Tor hides the fact that you are running a Bitcoin node
- Transaction origin hiding — when you broadcast a transaction, the first-hop observer sees only your Tor exit or .onion address
However, Tor adds latency (typically 200-500ms per hop) and can be subject to Sybil attacks at the Tor relay level. Bitcoin Core's Tor integration includes protections against some of these issues, such as separate address manager buckets for Tor and clearnet peers.
I2P Support
Bitcoin Core 22.0 (2021) added native I2P (Invisible Internet Project) support. I2P is a separate anonymity network from Tor with a different architecture — it uses unidirectional tunnels and a distributed network database rather than Tor's directory authority model. I2P tends to have lower latency than Tor for Bitcoin's use case because it is optimized for peer-to-peer traffic rather than web browsing.
Bitcoin nodes can operate simultaneously on clearnet (IPv4/IPv6), Tor, and I2P, maintaining separate connection pools across all three networks. This multi-network approach improves resilience: an attacker would need to compromise all three networks simultaneously to fully isolate a node.
Eclipse Attacks and Countermeasures
An eclipse attack is an attack on a Bitcoin node's view of the network. The attacker monopolizes all of the victim's peer connections, feeding it a filtered or fabricated view of the blockchain. An eclipsed node can be tricked into accepting invalid blocks, double-spent transactions, or having its mining power wasted on a stale chain.
How Eclipse Attacks Work
The attacker's strategy is to fill the victim's address manager with IP addresses of nodes the attacker controls (Sybil nodes). When the victim restarts and reconnects, it draws peer addresses from its address manager — and if the attacker has sufficiently polluted it, all outbound connections go to attacker-controlled nodes. Inbound connections can be similarly monopolized by the attacker aggressively connecting to the victim.
Countermeasures in Bitcoin Core
Bitcoin Core implements multiple layers of defense against eclipse attacks:
- Bucketed address storage — the addrman uses separate buckets keyed by source IP group and address IP group, making it hard for a single attacker to dominate many buckets
- Outbound connection diversity — Bitcoin Core ensures that outbound connections go to different /16 networks, preventing a single entity from monopolizing connections even if it controls many IPs within one network
- Anchor connections — two outbound connections are persisted across restarts (called "anchor" connections), making it harder for an attacker to replace all connections during a restart
- Block-relay-only connections — Bitcoin Core maintains 2 outbound connections used exclusively for block relay (no transaction or address gossiping). These are "stealthy" — an attacker probing the node's connections cannot detect them, making eclipse attacks harder
- Feeler connections — the node periodically makes short-lived "feeler" connections to random addresses in its new table, testing whether they are reachable and moving them to the tried table if so. This keeps the address manager fresh.
ASN-Level Analysis of Bitcoin Node Distribution
Examining Bitcoin node distribution through the lens of autonomous systems reveals important facts about the network's centralization risks. Despite Bitcoin's decentralization philosophy, node hosting is heavily concentrated in a handful of ASes and geographic regions.
The top autonomous systems hosting Bitcoin nodes include major hosting providers and residential ISPs:
- AS24940 — Hetzner Online (Germany) — one of the largest hosts of Bitcoin full nodes, owing to cheap dedicated servers in European data centers
- AS16509 — Amazon AWS — cloud-hosted nodes, primarily in us-east-1 and eu-west-1 regions
- AS14061 — DigitalOcean — popular among hobbyist node operators
- AS8075 — Microsoft Azure
- AS7922 — Comcast — residential nodes in the United States
- AS3320 — Deutsche Telekom — residential nodes in Germany
This concentration creates an underappreciated risk: a single AS can affect a large fraction of Bitcoin's reachable nodes. If Hetzner (AS24940) decided to block port 8333, or if a BGP hijack rerouted traffic destined for a major hosting provider, hundreds of Bitcoin nodes could be simultaneously disrupted.
This is one reason Bitcoin Core added ASN-aware peer selection in 2021. Instead of diversifying outbound connections only by /16 prefix, the node now diversifies by autonomous system number, using an ASN mapping table derived from BGP data. This means that even if an attacker controls many IP addresses, they would need addresses across many different autonomous systems to eclipse a node — a much harder requirement.
The ASN mapping used by Bitcoin Core is derived from the same BGP routing data that tools like this looking glass display. You can explore the ASes involved by looking up any node's IP address to see which autonomous system hosts it and what its AS path looks like.
Stratum V2: Decentralizing Mining Communication
While the Bitcoin P2P protocol handles node-to-node communication, there is a separate protocol for miner-to-pool communication: Stratum. The original Stratum protocol (V1), designed in 2012, is a simple JSON-RPC protocol over TCP where the pool sends work to miners and miners submit shares. It has a critical centralization problem: the pool has complete control over block template construction. Individual miners have zero say in which transactions go into a block.
Stratum V2 (SV2) is a ground-up redesign that addresses this and several other issues:
- Encrypted connections — Stratum V1 sends everything in plaintext, including miner authentication. An ISP or man-in-the-middle can intercept, observe, and even redirect hash power. SV2 uses AEAD encryption (Noise Protocol framework), preventing eavesdropping and making it impossible for intermediaries to steal hash power or censor miners.
- Binary protocol — SV2 replaces JSON-RPC with a compact binary format, reducing bandwidth by approximately 80% and improving parsing performance.
- Job declaration — the most significant change. SV2 introduces a Job Declaration Protocol that allows individual miners to construct their own block templates. The miner selects which transactions to include (from their own mempool), builds the candidate block, and declares it to the pool. The pool verifies the block is valid and assigns work against it. This shifts transaction selection power from pools back to miners, significantly improving Bitcoin's censorship resistance.
- Job distribution — pools can push multiple job templates to miners, allowing miners to immediately switch to mining on a new template when a block is found, reducing stale work.
The network topology implications are significant. Under Stratum V1, a handful of pool operators are the sole arbiters of transaction inclusion — an ISP or government that can pressure five pool operators could influence which transactions get mined. Under SV2 with job declaration, each of the thousands of individual miners makes independent transaction selection decisions, distributing this power in a way that mirrors Bitcoin's original design intent.
Network-Level Attacks Beyond Eclipse
Eclipse attacks are not the only network-layer threat to Bitcoin. The relationship between Bitcoin's overlay network and the underlying internet infrastructure creates several attack surfaces.
BGP Hijacking Against Bitcoin
A 2017 research paper ("Hijacking Bitcoin: Routing Attacks on Cryptocurrencies") demonstrated that BGP hijacking can be used to attack Bitcoin specifically. Because Bitcoin traffic is identifiable (port 8333, magic bytes in the protocol header), an AS-level attacker that performs a BGP hijack can selectively intercept Bitcoin connections, delay block propagation to specific miners, or partition the network. The researchers showed that just 100 prefixes cover over 30% of Bitcoin nodes, and a single /24 hijack announcement at a major Internet Exchange Point could intercept traffic for hundreds of nodes.
Countermeasures include running nodes on Tor or I2P (which hides the node's real IP from BGP-level attackers), using encrypted connections between nodes (BIP 324, discussed below), and the ASN-aware peer selection mentioned earlier. RPKI deployment across the internet would also help, as it makes BGP hijacking significantly harder.
Partitioning Attacks
An attacker with control over a critical piece of internet infrastructure — a major transit provider, a country-level firewall, or an IXP — could attempt to partition the Bitcoin network by selectively dropping or delaying Bitcoin traffic crossing a network boundary. China's Great Firewall has been studied as a potential partitioning point, since a significant fraction of mining hash rate historically operated within Chinese networks.
BIP 324: Encrypted P2P Transport
BIP 324, known as v2 transport protocol, was merged into Bitcoin Core 26.0 (2023). It replaces the unencrypted TCP transport with an encrypted channel using the ElligatorSwift key exchange (a variant of Diffie-Hellman that produces uniformly random-looking bytes) and ChaCha20-Poly1305 AEAD encryption.
BIP 324 serves two purposes. First, it prevents passive observers (ISPs, network taps) from identifying Bitcoin traffic by its protocol signatures — the encrypted stream is indistinguishable from random bytes, with no fixed magic bytes, no identifiable header structure, and variable-length encoding. Second, it prevents man-in-the-middle tampering with messages between nodes. While BIP 324 does not provide authentication by default (nodes do not verify each other's identity), it enables optional session-ID-based authentication for operators who want to ensure they are connected to a specific peer.
Geographic and Network Distribution
Bitcoin node distribution mirrors the broader internet's structure in some ways but diverges in others. Reachable nodes are heavily concentrated in:
- United States — roughly 25-30% of reachable nodes, spread across residential ISPs and cloud providers
- Germany — 15-20%, disproportionately high due to Hetzner's popularity and Germany's strong privacy culture
- France, Netherlands, Canada, UK — 3-7% each
From a BGP perspective, Bitcoin traffic flows through the same transit networks and peering arrangements that carry all internet traffic. A Bitcoin node in a residential network reaches its peers through the same AS paths and peering relationships that all other traffic uses. There is no separate "Bitcoin backbone" — the overlay network rides on the same infrastructure.
This is both a strength and a vulnerability. It means Bitcoin benefits from the internet's redundancy and global reach. But it also means Bitcoin is subject to the same BGP routing issues, hijacks, and infrastructure concentration that affect everything else on the internet. Understanding the network infrastructure that Bitcoin runs on — autonomous systems, BGP routing, peering relationships — is essential to understanding Bitcoin's real-world resilience.
The Road Ahead
Bitcoin's network protocol continues to evolve. Active areas of development include:
- Erlay (BIP 330) — set reconciliation for efficient transaction relay, discussed above, will reduce bandwidth and enable more peer connections
- Package relay (BIP 331) — evaluating groups of related transactions together, critical for Layer 2 protocols like the Lightning Network
- Improved peer selection — ongoing research into better algorithms for choosing and managing peer connections to resist eclipse and partition attacks
- QUIC-based transport — exploration of QUIC as an alternative to TCP for reduced connection establishment latency and better multiplexing
- Stratum V2 adoption — broader rollout of the job declaration protocol to decentralize block template construction
Each of these improvements reflects the same fundamental challenge: operating a trustless peer-to-peer network on an internet infrastructure that is itself built on trust — the trust between autonomous systems exchanging BGP routes, the trust between ISPs and transit providers, the trust that nobody is hijacking your traffic. Bitcoin's network layer is where cryptographic trustlessness meets the messy, political, sometimes adversarial reality of the internet's physical infrastructure.
Explore Bitcoin's Network Infrastructure
Use the BGP looking glass to explore the autonomous systems, IP prefixes, and routing paths that carry Bitcoin network traffic: