A light client verifies headers, not the rules themselves

Inherited archive entry · retained from the earlier edition. Its factual, legal and policy claims have not all been reverified for 19 September 2026. Research scope.

What a light client actually checks

Simplified payment verification was described in the original design, not bolted on afterward. The whitepaper's eighth section explains that a user only needs to keep a copy of the block headers of the longest proof-of-work chain, together with the Merkle branch linking a transaction to the block it is timestamped in. That proves a transaction was accepted into a block a network of miners built on top of; it does not involve the light client checking the transaction's validity itself. The paper is direct about the resulting exposure: the method is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker, and it suggests businesses handling frequent payments should still run a full node.

What bloom filters were added to solve

Left unmodified, a light client following that design would still need every node it queried to send it every transaction, so it could discard what was irrelevant locally. The BIP37 specification, dated 24 October 2012, replaces that with a probabilistic filter the client hands to its peer, so that remote peers throw away irrelevant transactions before sending them across the network. The trade is explicit in the BIP itself: a client can set a high false-positive rate, receiving some noise but leaving a peer unable to accurately know which transactions belong to the client, or a low rate that is bandwidth-efficient but lets remote peers correlate transactions with IP addresses.

The boundary a header and a filter do not cross

Verifying inclusion is not verifying the rules. The operating modes guide states the risk plainly: a full node can simply lie by omission, leading an SPV client to believe a transaction has not occurred, and a peer answering plain, unfiltered queries directly allows full nodes a complete view of the public addresses that correspond to the user. Filters were a mitigation for bandwidth and a partial mitigation for privacy, not a fix for either; a compromised or dishonest peer remains a single point a light client cannot detect on its own.

Questions to carry forward

• Is the wallet in question an SPV client relying on a small set of peers, and are those peers named or auditable?
• Does the product disclose its bloom filter's false-positive rate, or any privacy trade it has made on the client's behalf?
• For a high-value payment, has anything beyond header depth and inclusion actually been verified against network consensus?

A light client is a reasonable compromise for bandwidth, built into the design from the start; it was never a substitute for full validation, and the specification never claimed otherwise.