MASTERING-BITCOIN · Interactive Practice | Unit 11 · Video 6
| Concept | Description |
|---|---|
| BIP37 (old) | Client builds bloom filter of its addresses, sends to node — leaks privacy |
| BIP158 (new) | Node builds one filter per block, serves to many clients — no address leak |
| GCS encoding | Sort hashes → take deltas → Golomb-Rice encode the small deltas |
| Filter contents | Output scripts (created and spent), hashed with SipHash, truncated |
| Error model | False positives expected (wasted bandwidth); false negatives impossible |
| Verification | Today: compare 32-byte commitment across peers. Future: coinbase commitment |
The video shows that storing differences between sorted values yields smaller numbers than storing the values themselves. Smaller numbers need fewer bits.
Adjust the slider to see how many hashed items are in the filter. Notice the difference between the original sorted values (large) and the deltas (small).
⚙ interactive visualization — coming to this page format soon
Notice: As you increase the number of items, the deltas get smaller on average because the same range (0–1000) is divided into more gaps. Golomb-Rice coding turns each small delta into just a few bits. This is the heart of the GCS compression scheme used in BIP158.
The video uses two dice to illustrate why deltas tend to be small. Roll two dice and look at the absolute difference of their faces. The distribution leans hard toward zero.
The same intuition applies to uniformly distributed hashes: once you sort them and take differences, you get a similar decay pattern.
⚙ interactive visualization — coming to this page format soon
Reflect: A difference of 0 happens 6 times; a difference of 1 happens 10 times; differences of 4 or 5 are rare. When hashed transaction data is sorted, consecutive hashes behave the same way — tight clusters yield small deltas, and small numbers compress into just a few bits with Golomb-Rice.
Each script in a block is hashed and truncated to a fixed range. The smaller the range (fewer bits per entry), the smaller the filter — but the more accidental collisions.
A false positive means: the filter says "match" but no real coin of yours is in the block. You waste a block download. Crucially, the true positive rate stays at 100%.
Adjust the number of scripts in a block and the false positive rate parameter M (entries are hashed into the range , so a higher M means fewer collisions).
⚙ interactive visualization — coming to this page format soon
Notice: Doubling M roughly halves the false positive rate but only adds one more bit per entry to the filter size. This is why BIP158 picked M = 784 — a sweet spot giving roughly one false positive per ~784 queries while keeping filters compact. The asymmetry of the error model (100% true positives, occasional wasted bandwidth) is what makes this safe.
Question 1
What is the fundamental difference between BIP37 and BIP158 light-client protocols?
✅ Correct! The direction reversal is the core innovation — privacy becomes structural rather than a promise.
❌ Not quite. Focus on who computes the filter and which way it flows. That's the inversion BIP158 introduced.
Solution:
Under BIP37, the client built a bloom filter from its own addresses and handed it to a full node. That literally tells the node which addresses the wallet cares about — destroying privacy.
BIP158 flips the direction: each full node builds one filter per block and serves it to many clients. The client downloads filters and matches them locally. The client reveals nothing. It can even fetch matching blocks from different peers, mixing queries across the network.
The real innovation is the direction reversal, not better compression (though GCS is also more efficient than bloom filters).
Question 2
A wallet downloads a compact block filter, finds a match, fetches the full block, and discovers none of the transactions actually belong to it. What just happened, and what does it mean?
✅ Correct! False positives waste bandwidth but the 100% true positive guarantee holds. They can even add useful cover traffic.
❌ Not quite. A false negative would mean missing a real match — that's the impossible case. Missing-nothing-of-yours-in-a-matched-block is the other direction.
Solution:
This is a false positive. Because BIP158 hashes scripts with SipHash and truncates the output, two unrelated scripts can hash into the same 64-bit number. The filter says "match," the client downloads the block to check, and finds nothing of its own. Just a coincidence.
The error model is asymmetric:
A small false positive rate can even enhance privacy by acting as cover traffic: an observer cannot tell which block downloads correspond to real matches.
Question 3
True or False: A BIP158 compact block filter is built from outpoints (transaction ID + output index) so the wallet can track each specific coin by reference.
✅ Correct! Filters track scripts, which enables dedup and means the wallet only needs to remember its own scripts.
❌ Not quite. Recall the spend-visibility benefit: when a coin is spent, the filter must contain something the wallet already recognizes. That points to scripts, not outpoints.
Solution:
False. BIP158 filters track output scripts, not outpoints.
An output script is the locking program on a coin — what the wallet recognizes as "mine." Using scripts has three concrete benefits:
Tracking outpoints would require the wallet to remember every TXID it had ever received, which is far more state to maintain.
Question 4
Why does committing the filter's hash inside the coinbase transaction of each block (a proposed future upgrade) eliminate the need for multi-peer filter comparison?
✅ Correct! Filter integrity becomes consensus-enforced — verifiable with a header, a coinbase merkle proof, and the filter itself.
❌ Not quite. The coinbase isn't encrypted, and it doesn't store the whole filter. Think about what commitment means: a small hash that consensus rules force the miner to make honest.
Solution:
The coinbase is the first transaction in every block — the one that pays the miner — and it has spare data fields perfect for commitments.
If the filter hash lives in the coinbase, miners are effectively signing off on filter accuracy when they mine the block. The commitment is then secured by Bitcoin's consensus rules and proof of work.
A light client now needs only three pieces of data:
No multi-peer comparison. No statistical assumptions. Filter integrity is consensus-enforced. This is the philosophical endpoint: privacy preserved without trust.
Solved: 0 / 4