Merkle Block
A stripped-down block sent to SPV clients, containing only headers and minimal Merkle paths for relevant transactions.
A Merkle block is a Bitcoin peer-to-peer message (defined in BIP-37) that a full node sends to an SPV client. It contains:
- The full block header (80 bytes).
- The hashes of the transactions in the block that match the SPV client's Bloom filter.
- A Merkle proof (a partial Merkle tree) showing those transactions are committed in the block's Merkle root.
The matching transactions themselves are not in the message. The full node sends them right after it, as ordinary tx messages.
This is what lets a phone wallet check whether its transactions appeared in the latest block, without downloading the whole block.
The downside, which has gotten more attention over the years: Bloom filters leak privacy. The SPV client sends its filter to the full node, which can probabilistically reverse-engineer which addresses or transactions the client cares about. For a privacy-conscious user, this is a meaningful concern. BIP-37, written in 2012, expected clients to hide their addresses by choosing a looser filter, but a 2014 study found that a wallet using fewer than 20 addresses could reveal almost all of them.
The modern replacement is BIP-157/158 compact block filters: the server computes a filter per block, the client downloads it and checks for matches locally without revealing which addresses are theirs. Better privacy at modest bandwidth cost. Some mobile wallets use this approach rather than BIP-37 Merkle blocks.
As of October 2026, Bitcoin Core still implements merkle blocks. Since version 0.19.0.1 (November 2019), though, it serves them only when the node's operator turns Bloom filter support back on. The release notes gave denial-of-service risk as the reason.
Key takeaways
- Used by SPV wallets to confirm specific transactions in a block
- Contains minimal data: block header + Merkle path
- Saves bandwidth/storage, enabling lightweight verification
Corrected
-
Was: The entry said a merkle block message contains the transactions in the block that match the wallet's Bloom filter.
Now: A merkle block carries the block header and a partial Merkle tree holding the matching transactions' hashes. The full node sends the matching transactions themselves right after it, as separate tx messages. Details
-
Was: The entry said BIP 37 did not anticipate the privacy leak from Bloom filters when it was written in 2012, and that most modern mobile wallets, Phoenix and Mutiny among them, use the newer compact block filters.
Now: BIP 37 expected clients to hide their addresses by choosing a looser filter at the cost of extra bandwidth. A 2014 study found that a wallet using fewer than 20 addresses could still reveal almost all of them. Phoenix and Mutiny never used compact block filters, and the entry now says only that some mobile wallets do. Details
Sources (9)
- BIP 37 - Connection Bloom filtering (merkleblock is a block header plus a partial Merkle tree holding only the matching transactions' hashes; the transactions follow as separate tx messages; privacy section: clients trade false-positive rate against bandwidth)
- Gervais, Karame, Gruber and Capkun - On the Privacy Provisions of Bloom Filters in Lightweight Bitcoin Clients (2014)
- BIP 157 - Client Side Block Filtering
- Neutrino README - compact-block-filter light client designed for mobile Lightning clients
- Blixt Wallet README - mobile Lightning wallet with embedded lnd and Neutrino
- Bitcoin Core 0.19.0.1 release notes - peerbloomfilters now defaults to false, so the node no longer serves merkle blocks unless enabled (November 2019)
- Bitcoin Core - 0.19.0 release announcement: the download is version 0.19.0.1 (November 24, 2019)
- Bitcoin Core source - net_processing.h: DEFAULT_PEERBLOOMFILTERS is false (October 2026)
- Bitcoin Core source - net_processing.cpp: still sends MERKLEBLOCK messages to peers that set a filter (October 2026)
Related terms (8)
Published . Revised . Two corrections logged for this page.
Edit this page on GitHub