Block Propagation

This document explains how blocks propagate through the Bitcoin network, including the gossip protocol, validation process, and orphan block handling.

Block Propagation Flow

1. Block Discovery and Initial Broadcast

When a miner finds a new block:

1. Miner solves proof-of-work puzzle: Finds a valid nonce
2. Creates valid block: Includes transactions from mempool
3. Immediately broadcasts: Sends to all connected peers (8-10 first-hop nodes)
4. First-hop nodes validate: Each node checks the block
5. First-hop nodes forward: Send to their peers (50-100 second-hop nodes)
6. Your node receives: Eventually gets the block from one or more peers
7. Your node validates: Thoroughly checks the block
8. Your node forwards: Sends to peers who haven't seen it yet

2. Gossip Protocol Mechanism

Key Rule: Nodes never re-broadcast blocks back to the peer that sent them.

What happens:

• Peer A sends you the block
• You validate and accept it
• You forward to Peers D, E, F (but NOT back to Peer A)
• This prevents infinite loops and network flooding

3. Block Validation Process

Each full node performs complete validation:

1. Header Validation

   • Proof-of-work meets difficulty target
   • Timestamp is reasonable
   • Version is acceptable
   • Previous block hash is correct

2. Transaction Validation

   • All transactions are valid
   • No double-spends
   • Proper signatures
   • UTXO references are correct
   • Consensus rules compliance

3. Merkle Tree Verification

   • Merkle root matches transactions
   • Tree structure is valid

4. Chain Validity

   • Builds on valid previous block
   • Maintains blockchain integrity

Compact Block Relay (BIP 152)

Compact blocks dramatically reduce propagation bandwidth and latency:

How It Works

Instead of sending full blocks (~1-2 MB), nodes send:

1. Block header (80 bytes)
2. Short transaction IDs (6 bytes each)
3. Prefilled transactions (usually just the coinbase)

The receiving node reconstructs the full block using transactions already in its mempool.

Benefits

• 90% bandwidth reduction: Most transactions are already known
• Faster propagation: Smaller data means quicker transmission
• Reduced orphan rates: Faster propagation reduces stale blocks

Modes

Headers-First Synchronization

New nodes use headers-first sync for efficient IBD (Initial Block Download):

1. Download all block headers first (~60 MB total)
2. Validate the header chain (proof-of-work, timestamps)
3. Download full blocks in parallel from multiple peers
4. Validate blocks against downloaded headers

This allows nodes to verify they're on the correct chain before downloading gigabytes of block data.

Erlay Protocol

Erlay (BIP 330) improves transaction relay efficiency:

• Set reconciliation: Nodes exchange transaction set differences instead of full announcements
• 40% bandwidth reduction: For transaction relay
• Better connectivity: Enables more peer connections without bandwidth increase

Monitoring Block Propagation

Subscribe to New Blocks via ZMQ

Parse Block Header

Orphan Block Scenarios

Simultaneous Block Discovery

Sometimes two miners find blocks at nearly the same time, creating a temporary fork:

Block 850,000 (everyone agrees)
       |
       +-------------+-------------+
       |             |             |
  Block A      Block B (orphan) Block C
  (main chain)      |
       |        Block D
  Block E       (also orphaned)
  (main chain)
       |
    Winner!

Timeline of Fork Resolution

Time 0:00    Miner A finds Block A
Time 0:01    Miner B finds Block B (almost simultaneously)
Time 0:02    Network splits: some nodes see A first, others see B
Time 0:05    Some miners start building on Block A
Time 0:06    Other miners start building on Block B
Time 0:10    Block E found building on Block A
Time 0:11    Chain A is now longer (more proof-of-work)
Time 0:12    All nodes converge on Chain A
Time 0:13    Block B and Block D become orphans
Time 0:14    Orphaned transactions return to mempool

What Happens to Orphaned Blocks

• Block B and Block D are discarded
• Unique transactions from orphans return to mempool
• Miners' work on orphaned blocks is wasted
• Network automatically converges on longest chain
• This is why exchanges wait for 6 confirmations

Propagation Timing

Typical Network Performance

Factors Affecting Speed

Fast Propagation:

• Well-connected nodes (many peers)
• High-bandwidth connections
• Geographic proximity to miners
• Compact block relay enabled

Slow Propagation:

• Few peer connections
• Low-bandwidth connections
• Geographic distance from miners
• Firewall restrictions

Network Topology

Typical Node Connections

A typical Bitcoin node has:

• 8-10 outbound connections: You connect TO other nodes
• Up to 125 inbound connections: Other nodes connect TO you
• Diverse IP ranges: Protection against eclipse attacks

Connection Types

Security Considerations

Why Validation is Critical

Every node validates every block because:

• No central authority to trust
• Prevents invalid blocks from spreading
• Ensures consensus rules are followed
• Protects against malicious actors
• Maintains network integrity

If a node doesn't validate, it could spread invalid blocks and harm the network.

Economic Incentives

Miners are incentivized to:

• Find blocks quickly (first to market)
• Broadcast blocks immediately (avoid orphaning)
• Include high-fee transactions
• Follow consensus rules (avoid rejection)

Nodes are incentivized to:

• Validate blocks (maintain network health)
• Relay blocks quickly (help the network)
• Stay connected (receive updates)

Key Metrics

Summary

Bitcoin's block propagation mechanism is designed to be:

• Decentralized: No single point of failure
• Resilient: Multiple paths for block propagation
• Secure: Every node validates every block
• Efficient: Compact blocks reduce bandwidth by 90%
• Self-healing: Orphan blocks are automatically resolved

Resources

• mempool.space: Real-time block explorer and mempool visualization
• BIP 152: Compact Block Relay: Compact blocks specification
• Bitcoin Core P2P documentation: Network protocol details