Merkle Block

Overview

Bitcoin block headers commit to all block transactions through a Merkle root. A client interested in only a few transactions does not need every transaction hash to verify inclusion. A Merkle block supplies enough tree nodes to reconstruct the root while revealing the matching transactions.

The client compares the reconstructed root with the root in the block header. If they match, the included transaction hashes are cryptographically committed to that header. The client must still verify the header chain and determine whether the block belongs to the best valid chain.

Merkle blocks are associated with the `merkleblock` peer-to-peer message and Bloom-filter workflows defined in BIP37. These methods have privacy weaknesses because clients reveal filter information to peers. Newer compact block filter designs allow clients to download filters and perform matching locally.

Developers should distinguish a Merkle block from a complete block and from a generic Merkle proof. It is a specific Bitcoin serialization designed for partial transaction matching.

A successful proof confirms inclusion in one block, not transaction validity in isolation, spendability of outputs, or final settlement. Payment applications still need confirmation and reorganization handling.

Privacy limitations led many Bitcoin applications away from server-side Bloom filters. A peer serving Merkle blocks can infer which scripts or addresses interest the client from the filter it receives. Compact block filters reverse the model by letting the client download a generic filter and match locally. Developers maintaining older software should understand this privacy trade-off and avoid presenting partial-block retrieval as anonymous by default.