LearnBitcoin

Glossary

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 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)

Related terms (8)

Published . Revised . Two corrections logged for this page.

Edit this page on GitHub