In Chapter 11 we learned how to validate a Merkle block.
A full node can provide a proof of inclusion for transactions of interest through the
But how does the full node know which transactions are of interest?
A light client could tell the full node its addresses (or ScriptPubKeys). The full node can check for transactions that are relevant to these addresses, but that would be compromising the light client’s privacy. A light client wouldn’t want to reveal, for example, that it has 1,000 BTC to a full node. Privacy leaks are security leaks, and in Bitcoin, it’s generally a good idea to not leak any privacy whenever possible.
One solution is for the light client to tell the full node enough information to create a superset of all transactions of interest. To create this superset, we use what’s called a Bloom filter.
A Bloom filter is a filter for all possible transactions.
Full nodes run transactions through a Bloom filter and send
merkleblock commands for transactions that make it through.
Suppose there are 50 total transactions. There is one transaction a light client is interested in. The light client wants to “hide” the transaction among a group of five transactions. This requires a function that groups the 50 transactions into 10 different buckets, and the full node can then send a single bucket of transactions, in a manner of speaking. This grouping would have to be deterministic—that is, be the same ...