Bitcoin Address Lookup: A Question of Privacy

Every Bitcoin wallet faces a fundamental technical challenge: how do you discover which transactions belong to your addresses without revealing those addresses to others?

The solution you choose determines your privacy. Download everything and reveal nothing, or query servers and expose your financial history. There is no middle ground in the protocol design, only different points on the privacy-convenience spectrum.

Bitcoin's blockchain is public. Your addresses don't have to be.

Full nodes: the original standard (2009)

When Satoshi launched Bitcoin in 2009, there was only one way to use it: run a full node. Download the entire blockchain, every transaction ever made. Your node asks for everything, reveals interest in nothing.

How it works: Download every block, validate every transaction, maintain the complete UTXO set (~11 GB). When checking your balance, scan the local database. When broadcasting transactions, relay through the P2P network alongside thousands of others.

Privacy: Information-theoretic. Perfect. An adversary with unlimited computing power examining your network traffic learns precisely nothing about which addresses you control. Why? You downloaded the same data as every other node operator.

If everyone requests the same data, surveillance becomes mathematically impossible.

Cost: ~700 GB storage (or ~50 GB pruned), substantial bandwidth for initial sync, hours to days of synchronization. This is the cost of freedom.

Electrum: the convenience trap (2011)

In November 2011, as Bitcoin's blockchain passed a gigabyte, Thomas Voegtlin released Electrum to solve the "usability problem." Users wanted instant access without downloading the blockchain. The solution traded privacy for convenience.

How it works: Clients connect to Electrum servers and subscribe to SHA256 hashes of their scriptPubKeys. Your wallet transmits identifiers for every address you control directly to third-party servers. These servers maintain complete blockchain indexes and instantly return all transactions affecting your addresses.

The privacy catastrophe: The server knows:

• Every address in your wallet
• That these addresses belong to the same entity
• Your complete transaction history
• When you receive and spend coins
• Your IP address (absent Tor)
• Your spending patterns and timing

Electrum achieves instant synchronization because servers pre-index your addresses. Convenience comes from centralized coordination.

Blockchain analysis firms operate public Electrum servers. Users voluntarily connect and reveal their complete financial history.

Escape: Electrum Personal Server - run your own server backed by a full node, connect exclusively to your infrastructure. This eliminates third-party surveillance while preserving Electrum's user experience.

Block filters: privacy restored (2017-2019)

By 2017, developers recognized a crisis: full nodes (high resources) or Electrum (catastrophic privacy). BIP 157/158, proposed by Olaoluwa Osuntokun, Alex Akselrod, and Jim Posen, engineered a middle ground.

How it works: Full nodes generate deterministic compact filters (~20-30 KB per block) containing Golomb-Rice encoded sets of every scriptPubKey in that block. Clients download filters and check them locally to determine which blocks contain their transactions. Only then do they download those specific blocks.

The critical insight: servers never see your addresses. They never know which filters matched. They only observe which blocks you download after local processing.

Wasabi's pioneering implementation: Before BIP 157/158 were finalized, Wasabi Wallet (launched October 2018) implemented a custom filter protocol with different parameters, covering only SegWit transactions. Wasabi's backend generated these filters, demonstrating that privacy-preserving lightweight clients were practical at scale.

Wasabi combined filters with advanced Tor circuit management, preventing IP correlation. Every client gets identical filters. Every client checks matches locally. Clients download one block at a time from a random node. No server learns which addresses belong to which users.

Privacy: Nodes observe only which block you download. Your anonymity set equals all addresses in those blocks (2,000-5,000). False positive rate (~1/784,931) provides plausible deniability by downloading blocks in which you don't have any transactions. Correlation attacks require sophisticated adversaries with network visibility.

Cost: ~27 MB filter headers + ~170 MB filters + blocks with your transactions + occasional false-positive block downloads. Orders of magnitude less than full nodes, vastly superior privacy to address-transmitting architectures.

Utreexo: cryptographic compression (2019)

In June 2019, Tadge Dryja published the Utreexo paper: full-node privacy with sub-kilobyte state requirements through cryptographic accumulators - Merkle forests implementing dynamic hash-based state commitments.

How it works: Nodes store Merkle forest roots (~480 bytes), compressing the complete UTXO set to a cryptographic accumulator. Transactions arrive with inclusion proofs (Merkle branches proving the spent UTXOs exist). Your node verifies proofs against stored roots, updates the accumulator, discards proofs.

Bridge nodes (maintaining complete forests) generate inclusion proofs. Critical: bridges generate proofs for all UTXOs in a block simultaneously, never for individual addresses.

Privacy: Identical to full nodes. Bridges observe only which blocks you synchronize - information already public to nodes you connect to. They cannot perform targeted address queries because proof generation operates at block level. When you request a block's proofs, bridges provide proofs for every UTXO in that block, with no way to determine which ones you care about.

The bandwidth tradeoff: Utreexo's cryptographic compression has a cost. Ontop of having to download all blocks, in addition there is approximately 20% more bandwidth than a full node due to downloading inclusion proofs. For users with limited bandwidth (mobile connections, metered internet, satellite links), this is a significant penalty. Utreexo excels when storage is the bottleneck but bandwidth is available. For bandwidth-constrained environments, full nodes with pruning or block filters may be superior choices despite higher storage requirements.

Storage: ~480 bytes. Yet this provides identical privacy guarantees to storing 11 GB of UTXO data.

Privacy ranking

Tier 1 - Sovereign: Full nodes (2009) and Utreexo (2019) provide information-theoretic privacy. Full nodes via brute-force uniformity, Utreexo via cryptographic batch processing. Both make address-targeted queries protocol-impossible. Choose based on whether storage or bandwidth is your constraint.

Tier 2 - Degraded but Defensible: Block filters (2017-2019) leak block-level interest while maintaining address confidentiality. Anonymity sets of thousands, plausible deniability through false positives, no direct address disclosure. Acceptable for resource-constrained scenarios with Tor.

Tier 3 - Surveillance by Design: Electrum on public servers (2011) directly transmits address identifiers to third parties. Complete wallet topology revealed, transaction patterns monitored in real-time: using Electrum on public servers is volunteering for a surveillance database.

Choose your privacy model

Four architectures, four privacy models, all available today. Run a full node for perfect privacy, or Utreexo if storage is the bottleneck but bandwidth is available, or block filters over Tor if both resources are limited. Each maintains your privacy through a different mechanism.

Using Electrum on public servers means third parties know your complete transaction history. Whether this tradeoff is acceptable depends on your threat model, but understand what you're giving up.

Bitcoin provides the cryptographic tools for financial privacy. Whether you use them is a choice you make when selecting wallet software.