Block Announcement

What Is a Block Announcement?

A block announcement is a message sent by a Bitcoin node to inform its peers that a new block is available. When a miner finds a valid proof of work, the resulting block must reach every other node on the network as quickly as possible. The announcement mechanism determines how peers learn about the block, how much data they must download, and how fast they can begin validating it.

Block announcements sit at the heart of Bitcoin's consensus propagation. A node that has not yet heard about the latest block continues mining on top of the previous one, wasting hash power and risking an orphan block. The faster every node learns about a new block, the more secure and fair the network becomes.

How It Works

Bitcoin's block announcement protocol has gone through three major phases, each addressing bottlenecks in the previous approach.

Legacy Inv-Based Relay

In the original Bitcoin protocol, a node that received or mined a new block announced it by sending an inv (inventory) message containing the block's hash. The peer would check whether it had already seen that hash and, if not, request the full block data with a getdata message. The announcing node then transmitted the entire serialized block.

1. Node A mines or receives a new block and sends inv(block_hash) to each peer
2. Peer B checks its local chain: if it does not have the block, it replies with getdata(block_hash)
3. Node A sends the full block message containing every transaction
4. Peer B validates the block and repeats the cycle to its own peers

This approach was simple but wasteful. Every transaction in the block was transmitted even though most peers already held those transactions in their mempool. For a 1 MB block, that meant roughly 1 MB of redundant data per peer.

Headers-First Announcement (BIP 130)

BIP 130, authored by Suhas Daftuar and implemented in Bitcoin Core v0.12.0 (2016), introduced the sendheaders message. After exchanging this message during the handshake, a node can announce new blocks by sending their block headers directly instead of hash-only inv messages.

The key improvement: because Bitcoin Core uses headers-first sync, nodes need a valid header chain before they can process a block. Under the old inv flow, a peer had to make an extra getheaders round trip before requesting the block data. Sending the header directly eliminates that round trip for simple chain-tip extensions.

BIP 130 also improved reorg handling. Instead of announcing only the new tip hash during a reorganization, a node sends headers from the last fork point up to the new tip, letting peers request all intermediate blocks immediately.

Compact Block Relay (BIP 152)

BIP 152, authored by Matt Corallo and shipped in Bitcoin Core v0.13.0 (August 2016), introduced compact block relay. Rather than sending every transaction in a block, a node sends only the block header and a list of 6-byte short transaction IDs. The receiving node matches those IDs against its mempool and reconstructs the full block locally.

Short IDs are computed using SipHash-2-4, a fast keyed hash function. The keys are derived from a SHA-256 hash of the block header concatenated with a random nonce chosen by the sender. This makes ID collisions unpredictable across different senders, which prevents an attacker from crafting transactions that collide with legitimate ones.

# Compact block short ID derivation (simplified)
siphash_keys = SHA256(block_header || nonce)[0:16]
short_id     = SipHash-2-4(siphash_keys, wtxid) & 0xFFFFFFFFFFFF  # 6 bytes

If the receiver is missing any transactions (they were not in its mempool), it sends a getblocktxn request for those specific transactions. The sender replies with a blocktxn message containing only the missing ones. This avoids retransmitting the entire block.

High-Bandwidth vs. Low-Bandwidth Mode

BIP 152 defines two relay modes, letting nodes trade bandwidth for latency:

A node typically uses high-bandwidth mode with only a few of its fastest peers and low-bandwidth mode with the rest. High-bandwidth mode is activated via a sendcmpct message with the announce flag set to 1. In this mode, the sender pushes a cmpctblock message as soon as it verifies the header's proof of work, sometimes before full block validation is complete.

Protocol Versions

BIP 152 defines two protocol versions. Version 1 uses transaction IDs (txids) for short ID computation, while version 2 uses witness transaction IDs (wtxids). Since SegWit blocks must include witness data to validate, version 1 is effectively obsolete. Modern nodes negotiate version 2 during their handshake.

Why It Matters

Block announcement speed directly affects several properties of the Bitcoin network.

• Mining fairness: when a large mining pool discovers a block, every second of propagation delay gives that pool a head start on the next block. Faster announcements level the playing field for smaller miners and solo operators.
• Stale block rates: if two miners find valid blocks at nearly the same time, the slower-propagating block becomes stale. High stale rates waste energy, reduce effective security, and can incentivize selfish mining strategies.
• Block size scalability: efficient relay reduces the bandwidth penalty of larger blocks. Because compact blocks transmit only short IDs, a node can announce a full block in roughly 15 KB instead of 1 MB or more, decoupling block size from announcement overhead.
• Network decentralization: lower bandwidth requirements make it feasible for nodes on slower connections to stay synchronized, supporting a wider geographic distribution of full nodes.

For a deep technical dive into compact block relay performance, see Compact Block Relay: How BIP 152 Speeds Up Bitcoin Block Propagation.

Use Cases

Mining Operations

Mining pools rely on fast block announcements to minimize wasted work. When a competitor finds a block, the pool needs to learn about it and switch to building on the new tip as quickly as possible. Pools often maintain high-bandwidth compact block connections with other major pools and relay networks to shave milliseconds off propagation time.

Block Relay Networks

Specialized relay networks like the FIBRE (Fast Internet Bitcoin Relay Engine) were designed to further optimize block announcements between miners. These networks use techniques like forward error correction on top of compact blocks to achieve sub-second global propagation, reducing stale block risk to near zero.

Layer 2 and Spark

Layer 2 protocols such as Spark depend on timely block announcements for settlement finality. When a Spark user performs a unilateral exit to the Bitcoin base layer, the speed at which the exit transaction's block propagates across the network determines how quickly the exit is considered confirmed. Faster block propagation means more predictable confirmation times for on-chain settlement.

SPV and Light Clients

SPV clients and light clients use compact block filters (a separate mechanism from compact block relay) to stay synchronized. However, they still benefit from the headers-first announcement model introduced by BIP 130, which lets them track the chain tip efficiently without downloading full blocks.

Risks and Considerations

Mempool Divergence

Compact block reconstruction depends on the receiver already holding most of a block's transactions in its mempool. When mempools diverge significantly (for example, during periods of high congestion or when miners include non-standard transactions), the receiver must fall back to getblocktxn round trips. This adds latency and partially negates the speed advantage. During late-2024 congestion events, reconstruction success rates dropped well below typical levels before recovering after minimum relay fee adjustments in Bitcoin Core.

Invalid Block Relay

In high-bandwidth mode, a node forwards a compact block after checking only the header's proof of work, without fully validating the block. This means a miner could create a block with a valid header but invalid transactions, and it would still be relayed to high-bandwidth peers. The receiving node catches the invalidity during full validation and discards the block, but some bandwidth is wasted. This is an intentional trade-off: the latency savings of skipping validation before relay outweigh the occasional cost of forwarding an invalid block.

Short ID Collisions

With only 6 bytes per short ID, collisions are theoretically possible. If two transactions in a node's mempool produce the same short ID, the node cannot determine which one belongs in the block. BIP 152 handles this by falling back to requesting the full transaction via getblocktxn. The collision probability is extremely low under normal conditions because the SipHash keys are randomized per sender and per block.

Eclipse Attacks

If an attacker controls all of a victim's peer connections (an eclipse attack), they can delay or suppress block announcements entirely. The victim node would not learn about new blocks, potentially accepting double spends or mining on a stale chain. Defenses include connecting to diverse peers, using multiple outbound connections, and monitoring for anomalous block arrival times.

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.