Block Propagation

What Is Block Propagation?

Block propagation is the mechanism by which a newly discovered Bitcoin block travels from the miner who found it to every other node in the network. When a miner assembles a valid block and solves the proof-of-work puzzle, that block must reach all participants so they can update their copy of the blockchain and begin mining the next block.

The speed of this process directly affects mining fairness, network security, and decentralization. A miner who finds a block immediately begins working on the next one, while competitors remain unaware until the block reaches them. This information asymmetry creates a head-start advantage that compounds over time: miners who find more blocks accumulate more head starts, and more head starts lead to finding even more blocks.

In the early years of Bitcoin, blocks propagated slowly using a simple gossip protocol that transmitted every byte of every transaction. As blocks grew larger and mining became more competitive, a series of protocol optimizations transformed propagation from a major bottleneck into a largely solved problem.

How It Works

Block propagation follows a multi-hop relay pattern through Bitcoin's peer-to-peer network. The process begins when a miner finds a valid block and ends when the last node in the network has validated and accepted it.

The Traditional Pipeline

Before modern optimizations, propagation followed this sequence:

1. The miner discovers a valid block by finding a hash below the current difficulty target
2. The miner sends an inv (inventory) message to connected peers, announcing the new block hash
3. Peers that lack the block respond with a getdata request
4. The miner transmits the full block data
5. Receiving nodes validate the block (checking proof-of-work, transaction scripts, and the UTXO set), then repeat the process with their own peers

This approach required transmitting every transaction in full at each hop. A 1 MB block meant sending 1 MB to every peer, and each peer sending 1 MB to all of its peers. The result was median propagation times exceeding 6 seconds, with a long tail stretching past 40 seconds.

Compact Block Relay (BIP 152)

Compact block relay, introduced in Bitcoin Core 0.13.0 (2016), exploits a simple insight: most nodes already have the majority of a block's transactions in their mempool. Instead of transmitting full transactions, a compact block contains only 6-byte short identifiers computed via SipHash-2-4. The receiving node matches these identifiers against its mempool to reconstruct the complete block.

BIP 152 operates in two modes:

• High-bandwidth mode: peers proactively send compact blocks upon receipt, achieving delivery in 0.5 round trips. Nodes limit this to three peers to control bandwidth usage.
• Low-bandwidth mode: the default for most connections. Nodes send a header announcement first, and the peer requests the compact block only if needed. This adds latency (1.5 round trips) but conserves bandwidth.

If the receiver is missing any transactions (not present in its mempool), it sends a getblocktxn request for just the missing ones. In practice, well over 60% of blocks propagate without needing any extra round trips. The coinbase transaction is typically pre-filled in the compact block since it is unique to each block and cannot exist in any node's mempool.

Measurements from the KIT DSN research group showed compact blocks reduced 50th-percentile propagation delay by 90.1% and 90th-percentile delay by 87.6%.

Relay Networks

Dedicated relay infrastructure further accelerates propagation for miners and pools:

• Bitcoin Relay Network (2013 to 2016): created by Matt Corallo, this network of specialized relay nodes on Amazon Web Services connected the majority of mining pools. It used TCP and an optimized protocol to reduce hop latency.
• FIBRE (Fast Internet Bitcoin Relay Engine): Corallo's successor to the Relay Network, FIBRE uses UDP with forward error correction (FEC). FEC encodes redundant data into transmissions so receivers can reconstruct blocks even if some packets are lost, eliminating TCP's retransmission delays. FIBRE achieved near speed-of-light propagation times across continents.
• Falcon: developed at Cornell University, Falcon used "cut-through routing" where nodes forward each packet immediately upon arrival rather than waiting for the entire block. Having multiple independent relay networks was important for avoiding single points of failure.

In 2024 to 2025, Localhost Research revived FIBRE by rebasing it against Bitcoin Core v30 and deploying six public nodes across New York, Seattle, Tokyo, Beijing, Frankfurt, and London. Unlike the original single-maintainer operation, the revived network includes open-source monitoring tools so multiple parties can operate relay nodes.

Validation Caching

Block validation is the other half of the propagation bottleneck. Even after receiving a block, a node must verify every transaction before relaying it further. Bitcoin Core uses several caching strategies to speed this up:

• Signature cache: when transactions enter the mempool, their script signatures are validated and cached. When those transactions later appear in a block, the cached results are reused, avoiding redundant cryptographic verification.
• UTXO cache: the UTXO set is the primary validation bottleneck. Bitcoin Core 0.15 improved caching so the entire allocated memory is used effectively, reducing disk flushes.
• Headers-first download (Bitcoin Core 0.10): nodes download 80-byte block headers first, verify proof-of-work, then fetch block bodies in parallel from multiple peers using a 1,024-block moving window.

Why It Matters

Block propagation speed has direct consequences for network health, mining economics, and Bitcoin's decentralization properties. Understanding these dynamics is essential for anyone evaluating mining economics or the security assumptions of Layer 2 solutions.

Stale Block Rates

When two miners find valid blocks at nearly the same time, only one survives. The losing block becomes "stale," and the miner who found it receives no block subsidy. Slower propagation widens the window for these collisions.

Historical data illustrates how optimizations changed the landscape:

Mining Fairness and Centralization

Propagation delay creates a structural advantage for large mining pools with optimized infrastructure. Research shows that one major pool gained between 0.5% and 1.9% additional blocks per week from its low-latency connectivity alone. While this seems small, mining operates on thin margins, and the effect compounds over time.

The dynamic works through several mechanisms:

• Large pools with relay network access receive and propagate blocks faster, reducing their stale block rate
• Small independent miners with slower connections lose a disproportionate share of their blocks to stale races
• The economic incentive pushes smaller miners to join larger pools, concentrating hashrate
• Larger blocks amplify the problem: more data means longer transmission, extending the head-start window for well-connected miners

This centralization pressure was a key argument in Bitcoin's block size debate, and it remains relevant today. In March 2026, Bitcoin experienced a rare two-block chain reorganization when AntPool and Foundry USA each found valid blocks within 12 seconds of each other, demonstrating that propagation races still occur.

Use Cases

Mining Pool Infrastructure

Mining pools invest heavily in propagation infrastructure because every millisecond of delay translates to lost revenue. Pools deploy relay nodes in data centers worldwide, optimize their block templates for fast compact block reconstruction, and maintain high-bandwidth peering with other major pools. For a deeper look at pool economics, see the Bitcoin mining economics research.

Network Monitoring

Researchers and node operators monitor propagation metrics to assess network health. The KIT DSN Bitcoin Network Monitor, for example, tracks propagation delays over time and has recorded anomalies like a May 2023 spike where the 50th percentile jumped from under 1 second to over 5 seconds, likely caused by mempool divergence. These measurements help identify bottlenecks and validate protocol improvements.

Protocol Development

Ongoing protocol improvements target propagation efficiency. Erlay (BIP 330) uses set reconciliation to reduce transaction relay bandwidth by roughly 40%. While Erlay targets transaction relay rather than block relay, better transaction propagation keeps node mempools more synchronized, which makes compact blocks more effective by reducing the number of missing transactions that require extra round trips.

Risks and Considerations

Selfish Mining

Selfish mining exploits propagation delay directly. In this attack, a pool withholds newly found blocks and releases them strategically to waste honest miners' work. The attack becomes profitable above roughly 33% of total hashrate with no connectivity advantage, but the threshold drops to about 25% if the attacker has superior network connectivity that lets its blocks win propagation races.

Research has shown that when accounting for realistic propagation delays, there may always be some selfish mining strategy that outperforms honest mining regardless of attacker size. Faster network-wide propagation shrinks this attack surface by reducing the information asymmetry window.

Block Size Tradeoffs

Propagation time scales with block size in naive implementations. While compact blocks largely decouple block size from propagation bandwidth, larger blocks still increase validation time and the probability of mempool mismatches. Proposals for larger blocks must account for propagation effects on mining fairness, which is one reason Bitcoin maintains its current block weight limit.

Layer 2 solutions like the Lightning Network and Spark address scaling without increasing base-layer block size, avoiding propagation-related centralization pressure while enabling higher transaction throughput.

Relay Network Centralization

While relay networks dramatically improve propagation speed, they introduce their own centralization risk. A relay network operator in a position of power could selectively delay certain blocks or miners. This is why having multiple independent relay networks (such as FIBRE and Falcon operating simultaneously) was considered important for network health.

Network Partitions

Eclipse attacks can isolate individual nodes from the broader network, preventing them from receiving new blocks. Even without targeted attacks, network partitions caused by ISP failures or geographic routing issues can delay propagation to specific regions, creating localized double-spend risks during the partition.

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