Chapter 8: Bitcoin Network: Nodes, Propagation, and the Peer-to-Peer Architecture

8.1 The Network as Bitcoin's Immune System

In December 2013, China's People's Bank issued a directive banning financial institutions from handling Bitcoin transactions. The price dropped sharply. Commentators predicted the end of Bitcoin in China. Yet within weeks, Chinese miners and node operators had adapted, routing around the restrictions. Trading volume on peer-to-peer exchanges actually increased. The network continued producing blocks every ten minutes, utterly indifferent to the policy announcement.

This episode reveals something fundamental about Bitcoin that protocol descriptions alone cannot capture. You can understand Bitcoin's script language, its UTXO model, and its proof-of-work mining — the subjects of Chapters 6 and 7 — and still miss the most remarkable engineering achievement of the system: the network layer that makes it all function without any central point of control.

Bitcoin's peer-to-peer network is not merely a communication substrate that carries transactions and blocks from point A to point B. It is the system's immune system — the mechanism by which Bitcoin detects invalid data, rejects malicious actors, routes around failures, and maintains a consistent shared state across tens of thousands of independent computers operated by strangers who have no reason to trust each other. Every other property of Bitcoin — its fixed supply, its censorship resistance, its permissionless nature — ultimately depends on the health and architecture of this network.

Consider what the network must accomplish. A user in Buenos Aires creates a transaction on their phone. Within seconds, that transaction must reach tens of thousands of nodes scattered across every continent. Each node must independently verify the transaction against its own copy of the blockchain. If the transaction is valid, nodes must store it in their memory pools and relay it to their peers. Eventually, a miner somewhere — perhaps in Texas, perhaps in Kazakhstan — must include that transaction in a block. That block must then propagate back across the entire network, and every node must independently verify it and update their local copy of the blockchain. All of this must happen without any central server, without any coordinator, without any single entity that all participants trust.

This chapter examines how Bitcoin accomplishes this feat. We will start with the different types of nodes that compose the network and the distinct roles each plays. We will trace the complete lifecycle of a transaction from the moment a wallet broadcasts it to the moment it achieves deep confirmation. We will explore the mempool — that roiling, ever-changing pool of unconfirmed transactions where the fee market plays out in real time. We will examine how blocks propagate and why propagation speed has profound implications for mining fairness. We will understand SPV verification, the elegant mechanism that allows lightweight clients to verify transactions without downloading the entire blockchain. We will confront the realistic threats to Bitcoin's censorship resistance and the ways the network can and cannot be attacked. And we will conclude with a practical exercise: running your own Bitcoin node on testnet.

By the end of this chapter, you will understand not just what the Bitcoin network does, but why it is designed the way it is — and where its genuine vulnerabilities lie.

8.2 Node Types and Roles

The Bitcoin network is composed of software instances called nodes — programs that implement the Bitcoin protocol and communicate with each other. But not all nodes are created equal. Different nodes serve different functions, store different amounts of data, and provide different levels of security to their operators. Understanding these distinctions is essential for evaluating claims about Bitcoin's decentralization and security.

8.2.1 Full Nodes

A full node is a program that independently validates every transaction and every block against the complete set of Bitcoin's consensus rules. When a full node receives a new block, it does not merely check the proof-of-work header. It downloads every transaction in the block, verifies every signature, confirms that no input is double-spent, checks that the coinbase reward does not exceed the allowed amount, validates the block's timestamp against the median-time-past rule, and enforces every other consensus rule in the protocol. If any rule is violated, the block is rejected entirely, regardless of how much proof of work was expended to create it.

This is the key property that makes full nodes the backbone of Bitcoin's security model. A full node operator does not need to trust anyone. They do not trust miners to follow the rules. They do not trust other nodes to relay valid data. They verify everything themselves. If every miner in the world colluded to create an invalid block — say, one that printed 100 BTC as a coinbase reward instead of the correct 3.125 BTC — a single full node running on a Raspberry Pi in someone's closet would detect and reject it.

Full nodes store the complete blockchain, which as of early 2026 is approximately 570 GB on disk. They also maintain a database of all unspent transaction outputs (the UTXO set), which is roughly 7-8 GB. During initial block download (IBD) — the process of syncing a new node from the genesis block to the current tip — the node must download and validate every block ever produced. On modern hardware with a good internet connection, IBD takes roughly 6-12 hours, though on older machines or slow connections it can take days.

Full nodes that accept incoming connections (typically on TCP port 8333) are called listening nodes or reachable nodes. These are the nodes that new peers can discover and connect to. Nodes behind firewalls or NAT that only make outgoing connections still validate everything but do not help bootstrap new nodes joining the network. The distinction matters because the number of reachable full nodes directly affects how easy it is for new participants to join the network.

💡 Key Insight: Full nodes enforce Bitcoin's rules. Miners propose new blocks, but full nodes decide whether to accept them. This is why the common claim that "miners control Bitcoin" is misleading. Miners control which valid transactions to include, but they cannot change the rules without the consent of the full node operators who validate their blocks.

8.2.2 Pruned Nodes

A pruned node performs exactly the same validation as a full archival node — it checks every transaction and every block against all consensus rules. The difference is that after validating old blocks, a pruned node discards the raw block data it no longer needs, retaining only the UTXO set and recent blocks. A pruned node with a 550 MB pruning target (the minimum allowed by Bitcoin Core) still validates the entire blockchain during IBD but ends up storing far less data on disk.

Pruned nodes cannot serve historical blocks to peers performing IBD. If a new node connects to a pruned node and requests block 200,000, the pruned node cannot provide it because it has already discarded that data. However, pruned nodes can relay new transactions and new blocks just as effectively as archival nodes. Since the introduction of BIP 159 (which allowed pruned nodes to signal their capability to serve recent blocks), pruned nodes have become first-class participants in the network.

Pruning is an important accessibility feature. It allows someone with a laptop and a 256 GB SSD to run a fully validating node. As the blockchain continues to grow — roughly 50-80 GB per year — pruning will become increasingly important for maintaining a broad base of full node operators.

8.2.3 SPV / Light Nodes

A light node (also called an SPV node, after the Simplified Payment Verification section of Satoshi's whitepaper) does not download or validate the full blockchain. Instead, it downloads only block headers — 80 bytes per block, totaling roughly 65 MB for the entire blockchain history. When a light node needs to verify that a particular transaction was included in a block, it requests a Merkle proof from a full node peer. The Merkle proof consists of the sibling hashes along the path from the transaction to the Merkle root in the block header. By recomputing the hash path, the light node can confirm that the transaction is included in a block with a valid proof-of-work header.

SPV verification is dramatically less resource-intensive than full validation. A light node can run on a smartphone with minimal bandwidth and storage. This is how most Bitcoin mobile wallets work. However, SPV verification comes with significant security tradeoffs that we will examine in detail in Section 8.7.

The core limitation is this: an SPV node can verify that a transaction is included in a block, but it cannot verify that the transaction is valid. It trusts that the proof-of-work behind the block header implies validity — an assumption that holds as long as a majority of hash power follows the consensus rules. An SPV node also cannot detect if a block omits valid transactions (censorship) because it only sees the transactions it specifically asks about.

8.2.4 Miners

Miners (and mining pools) run full nodes augmented with specialized block construction and proof-of-work computation capabilities. A miner's node maintains a copy of the mempool, selects transactions to include in a candidate block (typically prioritizing by fee rate), constructs the block header with a valid Merkle root, and then searches for a nonce that produces a hash below the difficulty target — the process described in detail in Chapter 7.

Miners are economically incentivized participants. They expend real-world resources (electricity, hardware) to produce blocks and receive the block subsidy plus transaction fees as compensation. This economic incentive is what aligns miner behavior with the network's rules: a miner who produces an invalid block wastes their electricity because the network's full nodes will reject it.

8.2.5 The Node Count Debate

How many full nodes does Bitcoin have? The answer is contentious because it depends on what you count. Bitnodes, a popular node-tracking service, reports approximately 15,000-20,000 reachable nodes as of early 2026. But this only counts nodes that accept incoming connections. Estimates of total nodes (including those behind firewalls) range from 40,000 to over 100,000, depending on the methodology used.

Some argue that the node count is declining relative to Bitcoin's market cap and user base, which weakens decentralization. Others argue that the absolute number of full nodes is less important than their geographic and jurisdictional diversity. A network with 10,000 nodes spread across 80 countries is arguably more censorship-resistant than one with 50,000 nodes concentrated in three countries.

📊 By the Numbers: Reachable Bitcoin nodes (early 2026): ~17,000. Estimated total nodes: ~60,000-100,000. Top countries: United States (~25%), Germany (~15%), France (~5%), Netherlands (~4%). Blockchain size: ~570 GB. UTXO set: ~7-8 GB. Minimum pruned storage: 550 MB.

The question of how many full nodes are "enough" has no definitive answer. What matters is that the barrier to running a full node remains low enough that any motivated individual can do so, and that enough nodes exist across enough jurisdictions that no single government or entity can shut them all down simultaneously.

8.3 Peer-to-Peer Network Architecture

Bitcoin's network is an unstructured, permissionless, gossip-based peer-to-peer (P2P) network. There are no special servers, no registration process, no central directory. Any computer running compatible software can join the network, and any participant can leave at any time without notifying anyone. Understanding how this network self-organizes is essential for understanding Bitcoin's resilience.

8.3.1 The Gossip Protocol

Bitcoin uses a gossip protocol (also called epidemic protocol or flooding protocol) to disseminate transactions and blocks. When a node receives a new valid transaction, it announces the transaction's hash (called an inventory vector or inv message) to all of its peers. Each peer that does not already have the transaction responds with a getdata message to request the full transaction. The node then sends the transaction in a tx message. The receiving peers validate the transaction, add it to their mempools, and in turn announce it to their peers. Through this cascading process, a transaction broadcast by a single node reaches the entire network within seconds.

The same mechanism applies to blocks. When a node receives a new valid block, it announces the block hash to its peers, who request and download the full block (or, more commonly now, a compact block representation — see Section 8.6). Each peer validates the block, updates their local blockchain, and propagates the announcement to their own peers.

This gossip-based approach has several crucial properties:

Redundancy. Each node maintains connections to multiple peers (Bitcoin Core defaults to 8 outbound connections and allows up to 125 total). A transaction or block typically reaches a node through multiple paths. This means that the failure or malice of any single peer does not prevent data from reaching a node — as long as at least one honest peer forwards it.

No single point of failure. Because there is no central relay server, there is no single target whose failure would disrupt the network. An attacker would need to compromise or disrupt the connections of individual nodes — a problem that scales linearly with the number of targets rather than being solvable by taking down one server.

Probabilistic latency. The time for a transaction to reach all nodes follows a log-normal distribution. Most nodes receive it within 2-5 seconds. Some nodes at the periphery of the network, or those with slow connections, may take 10-30 seconds. This is acceptable because Bitcoin targets 10-minute block intervals — exact second-level precision in propagation is not required.

8.3.2 Peer Discovery

When a new Bitcoin node starts for the first time, it faces a bootstrapping problem: how does it find other nodes to connect to? Bitcoin uses a multi-layered approach:

DNS Seeds. Bitcoin Core is compiled with a list of DNS seed hostnames (such as seed.bitcoin.sipa.be and dnsseed.bluematt.me). These are DNS servers operated by well-known community members that return the IP addresses of currently active Bitcoin nodes. A new node queries these seeds to get an initial set of peers. DNS seeds are not a central point of control because the node only uses them for the initial connection — once connected, it discovers additional peers through the network itself. The DNS seed operators cannot censor transactions or blocks; they can only provide (or withhold) IP addresses of nodes to connect to.

Addr Messages. Once connected to at least one peer, a node learns about additional peers through addr (address) messages. Nodes periodically share the IP addresses of other nodes they know about. Over time, each node builds a diverse set of potential peers. Bitcoin Core stores these addresses in a local database (called the peers.dat file) and uses them for future connections, reducing dependence on DNS seeds after the first startup.

Hardcoded Seeds. As a last resort, Bitcoin Core contains a hardcoded list of IP addresses of long-running stable nodes. This is only used if DNS seeds are unreachable — an extreme fallback to ensure the node can always bootstrap.

Manual Configuration. Users can manually specify peers using the -addnode or -connect configuration options. This is commonly used for running nodes behind Tor or for connecting specific nodes in a private network.

8.3.3 Network Topology

Bitcoin's network topology is not random. Nodes form clusters based on geographic proximity (due to lower latency), operator relationships, and network characteristics. Major mining operations, exchanges, and block explorers tend to be well-connected hubs with many peers. Individual users running nodes at home may have fewer connections and higher latency.

This organic topology creates a network that is robust against random failures (removing a random node has little effect) but potentially vulnerable to targeted attacks on high-connectivity hubs. The research community has studied Bitcoin's network topology extensively, and the findings inform ongoing protocol improvements. For example, Bitcoin Core's peer selection algorithm deliberately seeks connections to peers in diverse /16 IP ranges (the first two octets of an IPv4 address) to reduce the risk of connecting only to nodes controlled by a single entity.

⚠️ Security Note: The topology of your node's connections directly affects your security. If an attacker controls all of your node's peers — a situation called an Eclipse attack — they can feed you a false view of the blockchain. Bitcoin Core implements numerous defenses against Eclipse attacks, including diversifying peer connections across IP ranges, limiting the rate at which the peer database is updated, and anchoring connections to previously known peers.

8.3.4 Network Protocol Versions and Feature Negotiation

When two Bitcoin nodes connect, they exchange version messages that include the node's protocol version number, the services it supports, the current block height it knows about, and other metadata. This handshake allows nodes to negotiate capabilities. For example, a node that supports compact block relay (BIP 152) signals this in the version handshake so that its peers know to send compact blocks rather than full blocks.

The protocol version number has increased over the years as new features were added. Older nodes that do not support newer features can still participate in the network for basic transaction and block relay, but they miss out on efficiency improvements. This backward-compatible design allows the network to upgrade gradually without requiring all nodes to update simultaneously.

8.4 Transaction Lifecycle: From Broadcast to Confirmation

Understanding the complete lifecycle of a Bitcoin transaction — from the moment it leaves a wallet to the moment it achieves deep confirmation — is essential for reasoning about Bitcoin's security properties and user experience. Let us trace a single transaction through the system.

8.4.1 Transaction Creation

Alice wants to send 0.05 BTC to Bob. She opens her wallet software, which constructs a transaction as follows:

1. Input selection. The wallet selects one or more UTXOs (unspent transaction outputs) from Alice's set of available funds. If Alice has a UTXO worth 0.08 BTC, the wallet selects it as the input.

2. Output construction. The wallet creates two outputs: one paying 0.05 BTC to Bob's address, and one paying the change (0.08 - 0.05 - fee) back to a change address controlled by Alice.

3. Fee calculation. The wallet estimates an appropriate fee based on current network conditions. It does this by examining the current mempool (either its own, if the wallet runs a full node, or a fee estimation API). If the mempool is congested, a higher fee is needed to ensure timely confirmation. The fee is implicitly defined as the difference between total inputs and total outputs — there is no explicit "fee" field in the transaction.

4. Signing. The wallet signs the transaction with Alice's private keys, proving she is authorized to spend the input UTXOs.

5. Serialization. The signed transaction is serialized into the binary format specified by the Bitcoin protocol.

8.4.2 Broadcast

Alice's wallet broadcasts the transaction to the Bitcoin network. If Alice is running a full node, her node sends inv messages to its peers. If she is using a light wallet, the wallet sends the transaction to one or more full nodes it is connected to (or to a wallet provider's server, which then relays it).

The moment a transaction is broadcast, it begins propagating through the gossip network. Each node that receives it performs an initial set of validation checks before relaying it further:

• Is the transaction syntactically valid (correct format, valid field sizes)?
• Do the referenced inputs exist in the UTXO set (or in the node's mempool, for chains of unconfirmed transactions)?
• Are the signatures valid?
• Does the transaction satisfy the standard script templates (for relay policy, not consensus)?
• Does the fee rate meet the node's minimum relay fee threshold (default: 1 sat/vB)?
• Does the transaction conflict with any transaction already in the node's mempool (no double-spends)?

If all checks pass, the node adds the transaction to its mempool and announces it to its peers. If any check fails, the transaction is rejected, and the node may penalize the peer that sent it (potentially disconnecting peers that repeatedly send invalid data).

8.4.3 Mempool Residence

The transaction now sits in the mempools of nodes across the network. The mempool (short for memory pool) is each node's local collection of valid but unconfirmed transactions. There is no single "the mempool" — every node has its own, and they can differ because of propagation delays, different relay policies, and different fee thresholds.

While in the mempool, the transaction waits to be selected by a miner for inclusion in a block. The time spent waiting depends primarily on the fee rate Alice attached. During periods of low congestion (roughly 1-3 sat/vB is sufficient), the wait may be just one block — about 10 minutes. During severe congestion (as seen during the Ordinals craze of 2023, when fee rates spiked above 500 sat/vB), low-fee transactions may wait hours, days, or even be evicted from mempools that reach their size limits.

8.4.4 Miner Selection and Block Inclusion

When a miner constructs a candidate block, they select transactions from their mempool to maximize revenue. The standard algorithm is greedy selection by fee rate: transactions paying the highest fee rate (measured in satoshis per virtual byte, or sat/vB) are selected first, until the block is full (the weight limit is 4 million weight units, roughly equivalent to 1-1.5 MB of serialized transaction data under SegWit).

There are complications. Some transactions depend on other unconfirmed transactions (child transactions spending the output of a parent that is also in the mempool). The miner must include the parent before the child. The ancestor fee rate — the combined fee rate of a transaction and all its unconfirmed ancestors — determines its priority, not just the transaction's individual fee rate.

Once the miner's block template is constructed, the mining hardware searches for a valid proof-of-work. When found, the miner broadcasts the new block to the network.

8.4.5 Confirmation

Nodes receive the new block, validate it (proof-of-work, all transactions, all consensus rules), and if valid, extend their local blockchain by one block. Alice's transaction is now said to have 1 confirmation. Each subsequent block built on top of the block containing Alice's transaction adds another confirmation. The conventional wisdom:

• 1 confirmation: Suitable for small payments. An attacker would need to find a new block faster than the rest of the network to reverse it.
• 3 confirmations: Adequate for moderate amounts. Reversing it requires sustaining a secret chain for 3 blocks.
• 6 confirmations: The traditional standard for large payments and exchange deposits. The probability of a 6-block reorganization is negligible under normal conditions (requires controlling more than 50% of hash power for an extended period).

🔗 Connection to Chapter 7: The security of confirmations directly depends on the mining difficulty and hash rate distribution discussed in the previous chapter. A confirmation on a blockchain with low hash power provides far less security than one on a blockchain with enormous hash power, even though the protocol mechanics are identical.

8.4.6 What Can Go Wrong

Several failure modes are possible during this lifecycle:

Double-spend attempt. Alice broadcasts two conflicting transactions — one paying Bob, one paying herself. Both enter the network, but nodes accept whichever they see first and reject the second as a double-spend. However, different nodes may see different transactions first. The conflict is only definitively resolved when one of the transactions is included in a mined block. This is why merchants accepting unconfirmed transactions (zero-confirmation, or 0-conf) are exposed to double-spend risk.

Transaction stuck at low fee. If Alice's fee is too low relative to current demand, her transaction may linger in the mempool. After 14 days (the default mempool expiration time in Bitcoin Core), unconfirmed transactions are dropped from nodes' mempools. Alice would need to rebroadcast or use Replace-By-Fee (RBF) to increase the fee.

Reorganization. In rare cases, two miners find blocks at approximately the same time, creating a temporary chain split. Nodes follow the chain with the most cumulative proof of work. Transactions confirmed in the losing block are returned to the mempool and must be re-mined. This is why a transaction with only 1 confirmation has a small but nonzero chance of being "unconfirmed."

8.5 The Mempool and Fee Market

The mempool is one of Bitcoin's most misunderstood components. It is simultaneously a technical data structure, an economic marketplace, and a real-time barometer of network demand. Understanding how the mempool functions is essential for anyone who uses Bitcoin, builds on it, or analyzes it.

8.5.1 The Mempool as a Priority Queue

Conceptually, you can think of each node's mempool as a priority queue ordered by fee rate. The highest-fee-rate transactions sit at the top, ready to be included in the next block. The lowest-fee-rate transactions sit at the bottom, at risk of eviction if the mempool grows too large.

Bitcoin Core's default maximum mempool size is 300 MB of transaction data. When the mempool exceeds this limit, the lowest-fee-rate transactions are evicted to make room. The minimum fee rate to enter the mempool — called the mempool minimum fee — rises dynamically as the mempool fills. During the extreme congestion events of May 2023 and December 2023, the mempool minimum fee rose above 20 sat/vB, meaning transactions paying less than that were not even accepted for relay.

Each block has a fixed maximum capacity (4 million weight units). With average transaction sizes around 250-400 virtual bytes, a typical block contains 2,000-4,000 transactions. If the mempool contains 50,000 waiting transactions, only the top tier will make it into the next block. This supply-demand imbalance is the foundation of Bitcoin's fee market.

8.5.2 Fee Rate and Transaction Pricing

Bitcoin transaction fees are not fixed. They emerge from a competitive market where users bid for scarce block space. The relevant metric is the fee rate, measured in satoshis per virtual byte (sat/vB).

A satoshi is the smallest unit of Bitcoin: 1 BTC = 100,000,000 satoshis. A virtual byte (vB) is a measure of transaction size that accounts for SegWit's weight discount. A typical single-input, two-output SegWit transaction is about 140-150 vB. At a fee rate of 10 sat/vB, this transaction would cost approximately 1,400-1,500 satoshis, or about $1.50 at a BTC price of $100,000.

Fee rates fluctuate dramatically. During quiet periods (weekends, holidays, bear markets), 1-2 sat/vB is often sufficient for next-block confirmation. During congestion events, fee rates for next-block inclusion can spike above 100, 200, or even 1,000 sat/vB. This variability is a feature of the system, not a bug — it reflects the real-time supply and demand for Bitcoin block space.

8.5.3 Fee Estimation

Wallets must estimate the appropriate fee rate for a desired confirmation speed. This is a prediction problem: what fee rate will be sufficient to be included in the next block, or within the next 3 blocks, or within the next 24 hours?

Bitcoin Core includes a built-in fee estimator (estimatesmartfee) that uses historical data about which transactions were included at which fee rates. Third-party services like mempool.space provide more sophisticated estimates based on real-time mempool analysis. The companion code file mempool_analyzer.py demonstrates how to query a node's mempool and analyze the fee distribution.

Fee estimation is inherently uncertain. A sudden spike in demand (a popular NFT mint, a market crash triggering a wave of exchange deposits) can invalidate fee estimates within minutes. Sophisticated users monitor the mempool in real time and adjust their fees accordingly.

8.5.4 Replace-By-Fee (RBF)

Replace-By-Fee (RBF), specified in BIP 125, allows a sender to replace an unconfirmed transaction with a new version that pays a higher fee. The replacement transaction must spend at least one of the same inputs as the original and must pay a fee rate at least 1 sat/vB higher than the original's fee rate (plus enough to cover the additional size of the replacement).

RBF is essential for fee market efficiency. Without it, a user who underestimates the required fee is stuck waiting indefinitely for their transaction to confirm (or for it to expire from the mempool after 14 days). With RBF, the user can "bump" their fee as congestion changes.

As of Bitcoin Core 24.0 (released in late 2022), full RBF (mempoolfullrbf=1) is supported as a configuration option. This allows replacing any unconfirmed transaction, not just those that were explicitly flagged with BIP 125's opt-in signal. Full RBF was controversial because it undermines the already-weak security of zero-confirmation transactions, but it reflects the reality that miners have always had the ability to include higher-fee replacements.

⚠️ Practical Warning: Never consider an unconfirmed Bitcoin transaction as "final." The combination of RBF and miners' economic incentives means that any unconfirmed transaction can be replaced if someone is willing to pay a higher fee. Wait for at least one confirmation for any transaction where finality matters.

8.5.5 Child-Pays-For-Parent (CPFP)

Child-Pays-For-Parent (CPFP) is a complementary fee-bumping technique. Instead of replacing the original transaction, the recipient creates a new transaction (the "child") that spends the output of the stuck transaction (the "parent") and attaches a high fee. Miners evaluating the child transaction realize they must include the parent to collect the child's fee. If the child's fee is high enough to make the combined ancestor fee rate attractive, both transactions get mined together.

CPFP is particularly useful when the sender did not opt into RBF, because the recipient can bump the fee without the sender's cooperation. It is commonly used by exchanges and payment processors to accelerate incoming deposits.

8.5.6 Fee Market Dynamics

The fee market exhibits several interesting dynamics:

Time-of-day effects. Transaction volume follows a diurnal pattern corresponding to business hours in North America and East Asia. Fees tend to be lowest during the weekend and during the overnight hours (UTC).

Batching incentives. Because fees are per-byte rather than per-BTC-transferred, entities that process many transactions (like exchanges) have strong incentives to batch multiple payments into a single transaction with many outputs. Batching can reduce total fee expenditure by 50-80%.

Block space as a commodity. Some researchers model Bitcoin block space as a commodity market, with miners as producers and users as consumers. The "supply" is fixed at roughly 4 million weight units per block (approximately one block every 10 minutes), while demand fluctuates with market activity, protocol events (like Ordinals inscriptions), and external factors.

SegWit adoption and fee pressure. The adoption of SegWit (Segregated Witness, discussed in a later chapter) increased the effective block capacity by approximately 60-70%. As SegWit adoption has increased to roughly 80-90% of transactions, this has moderated fee pressure. However, the introduction of Ordinals and BRC-20 tokens in 2023 created new demand for block space that overwhelmed this capacity increase.

8.6 Block Propagation

When a miner discovers a valid block, the speed at which that block reaches the rest of the network matters far more than you might initially expect. Block propagation speed has direct consequences for mining fairness, network security, and the rate of orphaned blocks.

8.6.1 Why Propagation Speed Matters

Consider two miners, Alice and Bob. Alice operates a large mining farm with excellent network connectivity — her blocks reach 90% of the network within 1 second. Bob operates a smaller mine in a remote location — his blocks take 10 seconds to reach the same coverage. During those 10 seconds when Alice's block has propagated but Bob's block has not, any new block found by the network will build on Alice's block, not Bob's. This gives Alice a systematic advantage beyond her fair share of hash power.

This phenomenon is called the propagation advantage, and it creates a centralizing pressure. Large miners with better connectivity earn slightly more than their hash rate proportion would suggest, while smaller or poorly connected miners earn slightly less. In the extreme case, if propagation delays are very long relative to the block interval, the network degrades toward a system where only the best-connected miner consistently wins — effectively centralizing mining.

8.6.2 Orphan Blocks and Stale Blocks

When two miners find valid blocks at approximately the same time (within a few seconds of each other), a temporary fork occurs. Some nodes see Block A first and some see Block B first. This is resolved when the next block is found: if it extends Block A, then Block B becomes a stale block (historically called an "orphan block," though this term is technically incorrect — an orphan block is one whose parent is unknown, while a stale block is one that lost a chain-tip race).

The stale block rate is a direct function of block propagation speed. If blocks propagate instantly, no stale blocks would ever occur. In practice, Bitcoin's stale block rate is approximately 0.1-0.5%, meaning roughly 1 in 200 to 1 in 1,000 blocks ends up stale. This rate has decreased over time as propagation improvements have been deployed.

Transactions in a stale block are not lost — they are returned to the mempool and can be included in a future block. However, the miner who found the stale block loses the block reward, which is a meaningful economic cost.

8.6.3 Compact Block Relay (BIP 152)

The most significant block propagation improvement is compact block relay, specified in BIP 152 and deployed in Bitcoin Core 0.13.0 (2016). The insight behind compact blocks is simple: by the time a new block is announced, most nodes already have most of the transactions in the block sitting in their mempools. Rather than transmitting the full block (which may be 1-2 MB), a node can send a compact block message containing the block header, a list of short transaction IDs (6-byte hashes), and the coinbase transaction. The receiving node matches the short IDs against its mempool to reconstruct the full block.

In the common case, the receiving node already has every transaction and can reconstruct the block immediately without any additional round trips. If some transactions are missing, the node requests them individually. In practice, compact block relay reduces block propagation data by 90-99%, dramatically speeding up propagation.

Compact blocks come in two modes:

• Low-bandwidth mode (default): The node announces the block hash via an inv message, and the peer requests the compact block. This adds one round trip but avoids wasting bandwidth if the peer has already received the block from another source.
• High-bandwidth mode: The node sends the compact block immediately without waiting for a request. This eliminates the round trip at the cost of sometimes sending data the peer already has. High-bandwidth mode is typically enabled for a node's first 3 peers.

8.6.4 The FIBRE Network and Mining-Specific Relays

For miners, even the improvement from compact blocks may not be sufficient. Milliseconds of propagation delay translate directly into reduced revenue over time. To address this, several specialized relay networks have been developed:

FIBRE (Fast Internet Bitcoin Relay Engine) was a network of servers optimized for Bitcoin block relay, using forward error correction (FEC) to reconstruct blocks even over lossy connections. Operated by Bitcoin Core developer Matt Corallo, FIBRE could propagate blocks across the globe in under 1 second. While the original FIBRE network has been wound down, its techniques have influenced Bitcoin Core's default relay behavior.

Mining pool relays. Large mining pools operate their own internal relay networks to ensure that blocks found by any pool participant reach the pool's block template server immediately. These private networks are not part of the public Bitcoin P2P network but play an important role in mining efficiency.

The existence of these specialized relay networks raises centralization concerns. If mining-specific relay infrastructure is necessary for competitive mining, and if this infrastructure is controlled by a small number of entities, it creates a potential chokepoint that could be used for censorship or favoritism.

8.6.5 Block Propagation Metrics

Researchers have measured Bitcoin block propagation extensively. As of recent measurements:

• Median propagation time to 50% of the network: 0.5-1.5 seconds
• Propagation time to 90% of the network: 2-5 seconds
• Propagation time to 99% of the network: 5-15 seconds

These times have improved dramatically since Bitcoin's early years, when propagation to 90% of the network could take 30-60 seconds. The improvements are attributable to compact block relay, better internet infrastructure globally, and the concentration of mining in well-connected facilities.

8.7 SPV Verification

In Section 8 of the original Bitcoin whitepaper, Satoshi Nakamoto described a method called Simplified Payment Verification (SPV) that would allow lightweight clients to verify transactions without running a full node. SPV is the foundation of nearly every Bitcoin mobile wallet, and understanding its mechanism and security properties is important for anyone who uses Bitcoin without running their own full node.

8.7.1 How SPV Works

An SPV client downloads and stores only block headers, not full blocks. Each block header is 80 bytes and contains, among other fields, the Merkle root — a cryptographic commitment to every transaction in the block (as constructed in Chapter 2's discussion of Merkle trees).

When an SPV client wants to verify that a transaction was included in a specific block, it requests a Merkle proof (also called a Merkle path or Merkle branch) from a full node. The Merkle proof consists of the sibling hashes at each level of the Merkle tree from the target transaction up to the root. Using these hashes, the SPV client computes the root hash and checks that it matches the Merkle root in the block header.

Here is a concrete example. Suppose a block contains 8 transactions (T0 through T7), and the client wants to verify T2. The Merkle tree looks like this:

           Root
          /    \
       H01      H23
      /   \    /   \
    H0  H1  H2  H3    ... (simplified)
    |   |   |   |
    T0  T1  T2  T3

To verify T2, the client needs: the hash of T3 (to compute H23's left child), the hash of H01 (the sibling of H23's branch), and the root hash (from the block header). By hashing T2 with T3's hash, then hashing the result with H01, the client computes what should be the root hash. If it matches the Merkle root in the header, the transaction is provably included in the block.

The proof is logarithmically sized: for a block with n transactions, the proof requires only log2(n) hashes. For a block with 4,000 transactions, the proof is just 12 hashes (384 bytes) — far smaller than downloading and validating the entire block.

8.7.2 Security Model of SPV

SPV verification proves that a transaction is included in a block with a valid proof-of-work. But it does not prove that the transaction is valid according to all consensus rules. An SPV client trusts, implicitly, that the majority of mining hash power is producing blocks that follow the consensus rules. If 51% of miners colluded to produce blocks containing invalid transactions, SPV clients would accept those blocks as valid because the headers would have valid proof-of-work.

This is a meaningful security reduction compared to full validation. Additional weaknesses include:

Privacy leakage. An SPV client must tell a full node which transactions it is interested in. This reveals information about the client's addresses and transaction patterns. Bloom filters (BIP 37) were designed to mitigate this by allowing the client to express interest in a fuzzy set of transactions, but research has shown that bloom filters provide much less privacy than originally hoped — a malicious full node can often deduce exactly which transactions the client is interested in by analyzing the filter parameters.

Transaction withholding. A full node connected to an SPV client can simply not relay certain transactions to the client, making it appear that a payment was never received. The SPV client has no way to detect this — it can only verify the presence of transactions, not their absence.

Lack of mempool access. SPV clients typically cannot monitor the mempool for unconfirmed transactions (doing so would require downloading all unconfirmed transactions, defeating the purpose of being lightweight). They rely on full node peers or third-party services for unconfirmed transaction data, introducing additional trust assumptions.

8.7.3 Improving SPV: Neutrino and BIP 157/158

The limitations of bloom filter-based SPV (BIP 37) motivated the development of compact block filters, specified in BIP 157 and BIP 158 (sometimes called "Neutrino" after the first prominent implementation). Instead of the client sending a bloom filter to the server, the server constructs a compact filter for each block that summarizes which addresses/scripts are affected by transactions in that block. The client downloads these filters and checks locally whether any of their addresses are included.

This approach inverts the privacy model. The client never reveals its addresses to the server — it downloads the same filter that every other client downloads. When the filter indicates a match, the client downloads the full block to extract the relevant transactions. The filters are small (roughly 15-20 KB per block) and can be verified against a commitment in the block header chain.

Compact block filters represent a significant improvement in SPV privacy, but the fundamental security limitation remains: SPV clients do not validate transactions and must trust that proof-of-work implies validity.

💡 Key Insight: The tradeoff between SPV and full validation is essentially a tradeoff between resource requirements and trust assumptions. A full node trusts no one and validates everything but requires hundreds of gigabytes of storage and hours of initial sync. An SPV client requires minimal resources but trusts that the majority hash power follows the rules. For most individual users transacting in moderate amounts, SPV is a reasonable tradeoff. For businesses, exchanges, and anyone handling significant value, running a full node is strongly recommended.

8.7.4 The companion code file spv_verification.py demonstrates the mechanics of SPV verification by constructing Merkle proofs and verifying them programmatically, building on the Merkle tree concepts introduced in Chapter 2.

8.8 Network Security and Censorship Resistance

Bitcoin is often described as "censorship-resistant." But what does this actually mean, and how robust is this property in practice? Answering this requires examining the specific mechanisms through which censorship could be attempted and the network's defenses against each.

8.8.1 What Censorship Means in Bitcoin

In the Bitcoin context, censorship means the deliberate exclusion of valid transactions from the blockchain. A censor wants to prevent specific addresses, entities, or transaction types from using the Bitcoin network. Censorship can be attempted at several layers:

Network-level censorship. Preventing transactions from propagating through the P2P network. This could involve blocking Bitcoin protocol traffic at the ISP or national firewall level, or controlling enough nodes to prevent a transaction from reaching miners.

Miner-level censorship. A miner or mining pool choosing not to include specific transactions in their blocks, even though the transactions are valid and paying adequate fees. Since miners select which transactions to include, they have the technical ability to exclude any transaction they choose.

Combined censorship. An entity with both network and mining power could attempt both: preventing the transaction from reaching other miners via the network, and refusing to mine it themselves.

8.8.2 Network-Level Censorship and Defenses

The most straightforward network-level censorship is blocking Bitcoin's TCP port (8333) at a firewall. This is easily circumvented by running Bitcoin over alternative ports, VPNs, or Tor. Bitcoin Core has included native Tor support since version 0.12.0 (2016), and a significant fraction of Bitcoin nodes (roughly 10-15%) are Tor-only or dual-stack (reachable over both clearnet and Tor).

Deep packet inspection (DPI) can potentially identify Bitcoin protocol traffic even on non-standard ports by analyzing the traffic patterns. However, encrypting Bitcoin traffic (which BIP 324, deployed in Bitcoin Core 26.0, now does by default for v2 transport connections) makes DPI-based identification significantly more difficult.

DNS seed blocking could prevent new nodes from bootstrapping, but as discussed in Section 8.3, nodes have multiple fallback mechanisms for peer discovery, including hardcoded seeds and manual configuration.

The most aggressive network-level censorship — fully disconnecting a country or region from the global internet — would prevent nodes in that region from participating, but the global network would continue operating normally. When connectivity is restored, nodes would sync the blocks they missed.

8.8.3 Miner-Level Censorship

Miner-level censorship is more subtle and harder to defend against. A mining pool controlling 30% of hash power that refuses to include transactions from a specific address imposes a delay: on average, those transactions would confirm 30% more slowly. A pool controlling 51% that refuses to include specific transactions could delay them indefinitely by orphaning any block that includes them.

However, miner-level censorship carries significant costs:

Opportunity cost. Censored transactions pay fees that the censoring miner forgoes. Other miners who include those transactions collect those fees. In a competitive market, this represents a direct revenue penalty for the censor.

Detection. Consistent censorship patterns are detectable. If a pool consistently excludes transactions that are valid and paying above-market fees, observers will notice. The Bitcoin community is vigilant about monitoring mining pool behavior, and pools that engaged in censorship would face reputational damage and potentially lose hash rate as miners switch to other pools.

Impermanence. Unless the censor controls a majority of hash power, censored transactions will eventually be included by non-censoring miners. Censorship becomes merely a delay, not a permanent exclusion.

8.8.4 Eclipse Attacks

An Eclipse attack targets a specific node by monopolizing all of its peer connections. If an attacker controls every peer a node is connected to, the attacker can:

• Filter transactions: Prevent the node from seeing specific transactions.
• Filter blocks: Deliver only blocks that exclude specific transactions.
• Deliver false chain tips: Show the node a chain that is not the longest valid chain.
• Facilitate double-spends: Show a merchant node a transaction, then withhold the block that includes a conflicting transaction.

Eclipse attacks are the most realistic targeted censorship attack against individual nodes. Bitcoin Core implements numerous defenses:

• Diverse peer selection: Nodes connect to peers across different /16 IP ranges.
• Anchor connections: Nodes maintain a set of persistent connections to previously validated peers, making it harder for an attacker to displace all connections.
• Outbound connection preference: Bitcoin Core makes all 8 default outbound connections itself (choosing which peers to connect to) rather than accepting all connections from incoming peers (which could be controlled by an attacker).
• Rate limiting peer database updates: Nodes limit how quickly new peer addresses can replace existing ones, preventing an attacker from flooding the peer database.

8.8.5 Sybil Attacks at the Network Level

A Sybil attack involves creating many fake identities (in Bitcoin's case, many nodes) to gain disproportionate influence over the network. Since running a Bitcoin node is permissionless and relatively cheap, an attacker could deploy thousands of nodes to increase the probability that other nodes connect to attacker-controlled peers.

Bitcoin's defenses against Sybil attacks overlap significantly with its Eclipse attack defenses. The key insight is that Bitcoin node identities are essentially IP addresses, and IP addresses in diverse ranges are harder to fake than a single identifier. By requiring diverse /16 ranges among peers, Bitcoin Core makes Sybil attacks expensive: the attacker needs IP addresses across many subnets, not just many addresses in a single subnet.

Additionally, Bitcoin's security model does not rely on majority-honest-nodes. It relies on majority-honest-hash-power. An attacker with 10,000 nodes but no hash power cannot produce invalid blocks that will be accepted by honest full nodes. The Sybil attack is primarily a vector for Eclipse attacks against specific targets, not a direct attack on the network's consensus.

⚖️ Nuanced View: Bitcoin's censorship resistance is not absolute. It is strongest against casual or unsophisticated censorship attempts and weakest against well-resourced state-level actors who control significant mining infrastructure. The concentration of mining in a small number of jurisdictions (primarily the United States, Kazakhstan, and Russia as of early 2026) means that coordinated regulatory action in these countries could meaningfully impact the network. Bitcoin's censorship resistance is best understood as a cost function — the question is not whether censorship is possible, but how expensive it is.

8.8.6 OFAC Compliance and Transaction Filtering

Since 2022, the intersection of mining pool compliance and financial regulation has become a live issue. The U.S. Treasury's Office of Foreign Assets Control (OFAC) maintains a sanctions list that includes specific Bitcoin addresses associated with sanctioned entities. Some mining pools, seeking to comply with U.S. regulations, have discussed or implemented policies of not including transactions involving OFAC-sanctioned addresses.

This represents a real-world test of Bitcoin's censorship resistance. If a significant fraction of hash power refuses to mine certain transactions, those transactions may experience confirmation delays. However, as long as some hash power is willing to include them (potentially miners operating in jurisdictions without equivalent sanctions), the transactions will eventually confirm. The debate over whether miners should or can be compelled to filter transactions is one of the most important ongoing discussions in Bitcoin governance.

8.9 Running a Bitcoin Node: Practical Guide

Understanding Bitcoin's network architecture theoretically is valuable, but there is no substitute for the understanding that comes from running your own node. This section provides a practical guide to running Bitcoin Core on testnet — Bitcoin's testing network where coins have no value.

8.9.1 System Requirements

To run a Bitcoin Core full node on testnet (not mainnet), the requirements are modest:

Testnet is ideal for learning because the blockchain is smaller, the coins are free (from faucets), and there is no financial risk.

8.9.2 Installation

Download Bitcoin Core from the official website (bitcoincore.org). Verify the download using the provided PGP signatures — this is important because a compromised Bitcoin Core binary could steal funds on mainnet. On Linux:

# Download Bitcoin Core (check for latest version)
wget https://bitcoincore.org/bin/bitcoin-core-26.0/bitcoin-26.0-x86_64-linux-gnu.tar.gz

# Verify the SHA256 checksum against the signed checksums file
sha256sum --check SHA256SUMS

# Extract
tar -xzf bitcoin-26.0-x86_64-linux-gnu.tar.gz

# Install binaries
sudo install -m 0755 bitcoin-26.0/bin/* /usr/local/bin/

8.9.3 Configuration

Create a configuration file at ~/.bitcoin/bitcoin.conf (Linux/macOS) or %APPDATA%\Bitcoin\bitcoin.conf (Windows):

# Run on testnet
testnet=1

# Accept incoming connections (optional, requires port forwarding)
listen=1

# Enable the JSON-RPC server for programmatic access
server=1

# RPC credentials (change these!)
rpcuser=myuser
rpcpassword=mypassword

# Reduce bandwidth usage
maxuploadtarget=500

# Enable transaction indexing (useful for learning, not required)
txindex=1

8.9.4 Starting and Syncing

Start the node:

bitcoind -testnet -daemon

Monitor the sync progress:

bitcoin-cli -testnet getblockchaininfo

The output includes a verificationprogress field (0.0 to 1.0) indicating how far through the blockchain the node has synced. On testnet, initial sync typically takes 1-4 hours depending on hardware and internet speed.

8.9.5 Exploring the RPC Interface

Once synced, Bitcoin Core's JSON-RPC interface provides a rich set of commands for interacting with the node programmatically. Some useful commands for exploration:

# Get network information
bitcoin-cli -testnet getnetworkinfo

# Get peer information
bitcoin-cli -testnet getpeerinfo

# Get mempool information
bitcoin-cli -testnet getmempoolinfo

# Get a specific block
bitcoin-cli -testnet getblock $(bitcoin-cli -testnet getblockhash 100)

# Get mempool contents
bitcoin-cli -testnet getrawmempool true

The RPC interface is what the companion code files (mempool_analyzer.py, network_topology.py) use to interact with the node. Running these scripts against your own testnet node provides hands-on experience with the concepts discussed throughout this chapter.

8.9.6 Connecting to the Testnet Faucet

To experiment with transactions on testnet, you need testnet coins. Bitcoin testnet faucets provide free testnet BTC. First, generate a receiving address:

# Create a new wallet
bitcoin-cli -testnet createwallet "learning"

# Generate a new address
bitcoin-cli -testnet getnewaddress

Copy the returned address and paste it into a testnet faucet website (search for "Bitcoin testnet faucet"). After the faucet sends coins to your address, you can observe the transaction arriving in your node's mempool and then being confirmed in a block — experiencing the complete transaction lifecycle described in Section 8.4 firsthand.

✅ Practice Exercise: After syncing your testnet node, use the getpeerinfo RPC command to examine your node's connections. How many peers are you connected to? What countries are they in (look up the IP addresses)? Are any connections over Tor? How diverse are the /16 ranges? This exercise connects directly to the peer discovery and Eclipse attack concepts from Sections 8.3 and 8.8.

8.10 Summary and Bridge to Chapter 9

This chapter has examined the network layer that makes Bitcoin function as a decentralized system. We have seen that the Bitcoin network is composed of different node types — full nodes that enforce every rule, pruned nodes that validate everything while conserving disk space, SPV nodes that trade security for efficiency, and miners that propose new blocks — each playing a distinct role in the system's security model.

The gossip protocol ensures that transactions and blocks propagate across the network within seconds, without any central coordination. Peer discovery mechanisms, starting from DNS seeds and expanding through address sharing, allow the network to self-organize. Compact block relay has dramatically reduced propagation times, improving mining fairness and reducing the stale block rate.

The mempool and fee market represent Bitcoin's first-price auction for scarce block space. Users compete for inclusion by offering higher fee rates, and mechanisms like RBF and CPFP allow dynamic fee adjustment as conditions change. The fee market is volatile and sometimes painful for users, but it is the mechanism that will fund Bitcoin's security as the block subsidy continues to halve.

SPV verification enables lightweight clients to verify transaction inclusion without downloading the entire blockchain, but with meaningful security and privacy tradeoffs. Full nodes remain the gold standard for security, and their accessibility is a critical factor in Bitcoin's long-term decentralization.

Bitcoin's censorship resistance is real but not absolute. It is a cost function: censoring transactions on Bitcoin is expensive, detectable, and impermanent (below the 51% threshold), but it is not impossible. The concentration of mining, the role of regulatory compliance, and the network's dependence on internet infrastructure create genuine vulnerabilities that the community actively works to mitigate.

In Chapter 9, we turn to the data structures at the heart of every Bitcoin node: the UTXO set and transaction validation. While this chapter examined how transactions and blocks move through the network, Chapter 9 examines how nodes determine whether those transactions and blocks are valid. We will explore the UTXO set as Bitcoin's definitive record of ownership, the script execution engine that enforces spending conditions, and the detailed validation rules that full nodes apply to every transaction and block they receive. The UTXO model — Bitcoin's alternative to the account-based model used by most other systems — is one of the protocol's most distinctive and consequential design decisions, and understanding it is essential before we can examine Bitcoin's more advanced features in Parts III and IV.