SPV checks headers, not the full state
Section 8 of the white paper describes simplified payment verification: keep the headers of the most-work chain and use a Merkle branch to check inclusion. The client verifies header proof of work and ordering without downloading every transaction.
It does not reconstruct the UTXO set or check every signature, script and issuance rule. It relies more heavily on miner incentives and on peers not hiding relevant information.
BIP 37 exposes a filter to the server
A BIP 37 wallet sends a Bloom filter made from watched keys, scripts and outputs. A full-node peer returns matches and a partial Merkle tree; false positives obscure the exact interest but increase traffic.
Repeated filters can still link addresses to each other and to a client's network connection. A malicious peer may omit data, and a proof of presence cannot demonstrate completeness.
BIPs 157 and 158 reverse the direction
A full node creates a deterministic compact filter for each block. The client downloads it, checks locally for its scripts and obtains the complete block after a match, rather than sending an address-derived query to each serving peer.
BIP 157 chains filter headers and defines P2P retrieval. Comparing peers helps expose a bad filter when at least one source is honest, though fetching matched blocks can still leave network clues.
Two meanings of compact
BIP 157/158 filters help light clients find relevant historical blocks. BIP 152 compact block relay reconstructs a newly announced block from transactions a full node already has in its mempool. They solve different problems.
A full node provides the strongest independent verification but costs resources and maintenance. A light client is a legitimate constrained-device trade-off when its interface honestly states what it verifies and where data comes from.