Privacy Problems of Bloom filters

Published by Mario Oettler on

In BIP37, bloom filters were suggested as a privacy-preserving technique for SPV wallets (Simple Payment Verification). Those clients request transactions from full nodes. Thereby they reveal the addresses they manage. This is a privacy concern because the full node can link those addresses to the IP address and find connections between those addresses.

With bloom filters, the node requests more addresses than it needs. This is because of the false-positive rate. And the idea is that the full node is lead to a wrong track, not knowing which addresses really belong to the requesting wallet.

Basically, there are three issues with bloom filters:

  1. Full nodes can inspect addresses and their transactions. They can group addresses according to the transactions between them. All addresses that don’t have a connection are very likely a false flag.
  2. When sending multiple bloom filters, full nodes can compare the encoded addresses. Overlapping addresses very likely belong to the wallet.
  3. In BIP37 the public key (pubkey) and the address (hashpubkey) are inserted into the filter. When reading the filter both public key and address need to match. But this reduces the likelihood of false positives dramatically.

To overcome those issues, other measures like client-side block filtering were introduced.