Compact Block Filters vs Electrum Server Comparison

Compact Block Filters vs Electrum: Overview

Bitcoin light clients need a way to find transactions relevant to their wallet without downloading the entire blockchain. Two dominant approaches exist: compact block filters (defined by BIP-157/158) and the Electrum server protocol. Each makes a fundamentally different tradeoff between privacy and efficiency.

Compact block filters let the client download a small Golomb-coded set (GCS) filter for each block, then match wallet addresses locally. The server never learns which addresses the client cares about. The Electrum model takes the opposite approach: the client sends its addresses to a server that maintains a full address index, and the server returns matching transaction history directly. This is faster and uses less bandwidth, but the server sees every address the wallet queries.

How Compact Block Filters Work

BIP-158 defines the filter construction. For each block, every output script and every input's previous output script is hashed into a set. That set is then compressed using Golomb-Rice coding, producing a compact filter roughly 1/50th the size of the block it represents. BIP-157 defines the peer-to-peer protocol clients use to request these filters from any full node that has peerblockfilters=1 enabled.

The client downloads filter headers first to verify the chain of filters, then downloads the filters themselves. For each filter, the client checks whether any of its own scriptPubKeys appear in the set. A match triggers a download of the full block from any peer. Because Golomb-coded sets are probabilistic, false positives occur at a configurable rate (BIP-158 uses P = 19, meaning roughly 1 in 2^19 false positive rate per element). The client occasionally downloads blocks with no relevant transactions, but this is a small bandwidth cost.

The total filter index for the entire Bitcoin blockchain is approximately 4 GB. A client syncing from the genesis block downloads all filters, which takes minutes to hours depending on connection speed. For wallets with a known creation date, filters before that date can be skipped, but the protocol does not natively support date-based pruning of filter downloads.

How Electrum Servers Work

Electrum servers maintain a complete index mapping every Bitcoin address (or more precisely, every script hash) to the transactions that reference it. When a wallet connects, it sends its addresses to the server, and the server returns full transaction histories and monitors for new activity via a subscription mechanism. This model is documented in the Electrum server architecture research article.

Three major server implementations exist, each with different resource tradeoffs:

• Electrs (Rust): lower disk usage (~30 GB index), higher CPU usage for queries, no transaction index required on Bitcoin Core
• ElectrumX (Python): moderate disk (~50-70 GB index), built-in peer discovery protocol, the original server used by the Electrum project
• Fulcrum (C++): fastest query performance (up to 8x faster than ElectrumX in benchmarks), but requires txindex=1 on Bitcoin Core and uses the most disk (~100-130 GB index)

Electrum Personal Server (EPS) is a lightweight alternative designed for single-user setups. Instead of indexing the entire blockchain, EPS only tracks wallets explicitly configured by the operator. It works with pruned Bitcoin Core nodes and uses minimal resources, but supports only one wallet connection at a time.

Privacy Comparison

Privacy is the primary reason to choose compact block filters over Electrum. With the Electrum model, the server operator learns every address the wallet owns. If the server logs requests (and many public servers do), a complete picture of the user's balance and transaction history is exposed. Even connecting to your own Electrum server only shifts trust to your own infrastructure and network path.

Compact block filters eliminate address leakage entirely. The server sends the same filter to every client, and matching happens locally. A residual information leak remains: the serving node observes which full blocks a client requests after a filter match. An adversary controlling the filter-serving node could narrow down which transactions the wallet cares about, but this is far less precise than the Electrum model. Clients can mitigate this further by requesting matched blocks from different peers than the filter source.

For users connecting over Tor, compact block filters pair naturally with onion routing since no identifying address data leaves the client. Running an Electrum server over Tor protects the connection but does not change the fact that the server itself sees the addresses.

Bandwidth and Sync Performance

The Electrum model is significantly more bandwidth-efficient in normal operation. A wallet querying its transaction history sends a list of script hashes and receives only matching transactions. Total data transferred per sync is typically under a few kilobytes.

Compact block filter clients download every filter for the range they're syncing. With filters averaging roughly 15-20 KB each and over 860,000 blocks in the chain, a full filter sync from genesis totals approximately 4 GB. After initial sync, ongoing bandwidth is modest: one filter per new block plus any matched full blocks. However, for a wallet that has been offline for weeks or months, catching up requires downloading all missed filters.

Address discovery is notably slower with compact block filters. An HD wallet recovering from a seed phrase must scan all filters for each derivation path up to the gap limit. With Electrum, the server returns full history for all addresses in one round-trip.

Server Resource Requirements

Running a compact block filter server requires minimal resources beyond a standard Bitcoin Core node. Enabling blockfilterindex=1 and peerblockfilters=1 in bitcoin.conf adds roughly 4 GB of disk usage and negligible CPU overhead. The node builds filters during normal block validation and serves them to peers on request.

Electrum servers demand significantly more resources. The address index is built by scanning the entire blockchain, which takes hours to days depending on hardware. For a comparison of Electrs, ElectrumX, and Fulcrum, see the node software comparison tool.

Wallet Support

Electrum protocol support is widespread across Bitcoin wallets. Electrum desktop and Sparrow are the most prominent desktop clients. Sparrow supports connecting to Electrs, ElectrumX, Fulcrum, EPS, or directly to Bitcoin Core. Mobile wallets like BlueWallet and Nunchuk also support Electrum server connections. The protocol's maturity means most Bitcoin wallet software has some form of Electrum server compatibility.

Compact block filter support is newer and concentrated in Lightning-adjacent projects. LDK added filter support for downloading confirmed transactions, and LND's Neutrino backend (by Lightning Labs) was the first major implementation. BDK-Kyoto brings BIP-157/158 to the Bitcoin Development Kit ecosystem. Mobile Lightning wallets including Blixt and Breez have used compact block filters for on-chain data.

LDK, BDK, and the Filter-Based Approach

The Lightning Development Kit (LDK) supports compact block filters as one of its chain data sources. This allows LDK-based wallets to monitor the blockchain for channel-related transactions without running a full node or trusting an Electrum server. For mobile Lightning wallets, this is a practical middle ground: the wallet maintains privacy while keeping resource usage within mobile constraints after initial sync.

BDK-Kyoto is a client-side implementation of BIP-157/158 designed as a chain source for BDK. It connects directly to the Bitcoin P2P network, downloads compact block filters, and provides wallet applications with relevant transactions. This approach eliminates the need for any server infrastructure beyond the Bitcoin network itself.

Layer 2 protocols like Spark can benefit from compact block filter availability. When a wallet needs to verify on-chain settlement transactions or monitor for force closes, filters provide a privacy-preserving way to watch the base layer without relying on third-party indexing infrastructure.

When to Use Each Approach

Choose compact block filters when privacy is non-negotiable and you accept slower initial sync. This is the right model for wallets that want to avoid trusting any third-party server with address information. It works well for Lightning node backends (as LND demonstrates) and for applications where the wallet stays online most of the time, since ongoing sync is lightweight once filters are caught up.

Choose the Electrum server model when speed and bandwidth efficiency matter more than hiding addresses from your server. If you run your own server at home, the privacy tradeoff is limited to your own infrastructure. This model excels at seed recovery, wallet imports, and any scenario requiring fast address lookups across the full blockchain history. For multisig coordinators and power users managing many addresses, the Electrum model's instant lookups are hard to replace.

Frequently Asked Questions

What are compact block filters in Bitcoin?

Compact block filters (defined by BIP-157/158) are compressed summaries of the scripts in each Bitcoin block. A light client downloads these filters and checks locally whether any of its addresses appear. If a filter matches, the client downloads the full block. This lets wallets find their transactions without revealing their addresses to any server.

Is Electrum server safe to use?

Using a public Electrum server means the server operator can see all addresses your wallet queries, which reveals your balance and transaction history. Running your own Electrum server connected to your own node eliminates this risk. For most users, the primary concern is privacy rather than fund security: the server cannot steal funds or forge transactions regardless of who operates it.

Do compact block filters use more bandwidth than Electrum?

Yes, significantly more for initial sync. A full filter download from genesis is approximately 4 GB, while an Electrum address lookup transfers only kilobytes. After initial sync, ongoing bandwidth is modest (one filter per block, roughly 15-20 KB), but still higher than Electrum's subscription notifications. The tradeoff is privacy: filters reveal nothing about which addresses the wallet holds.

Can I run compact block filters on a Raspberry Pi?

Yes. Serving compact block filters requires only Bitcoin Core with blockfilterindex=1 enabled, which adds about 4 GB of disk usage. A Raspberry Pi 4 with 4-8 GB of RAM and sufficient storage for the blockchain can serve filters. This is much less resource-intensive than running an Electrum server, which requires building and maintaining a large address index.

Which wallets support BIP-157 compact block filters?

LND's Neutrino backend is the most widely deployed implementation. LDK supports filters as a chain data source. BDK-Kyoto brings filter support to the BDK ecosystem. Mobile wallets including Blixt and Breez have used compact block filters. Bitcoin Core serves filters to peers but does not use them as a light client itself.

What is the difference between ElectrumX and Fulcrum?

ElectrumX is the original Python-based Electrum server with built-in peer discovery. Fulcrum is a C++ reimplementation focused on performance: benchmarks show it up to 8x faster than ElectrumX for address lookups. Fulcrum requires txindex=1 on Bitcoin Core and uses more disk space (100-130 GB vs 50-70 GB). For a detailed comparison, see the Electrum server architecture research article.

Can compact block filters replace Electrum servers entirely?

Not for all use cases. Compact block filters excel at privacy but are poor at fast address discovery, seed recovery, and serving multiple wallet types simultaneously. Electrum servers remain superior for applications that need instant historical lookups across arbitrary addresses. The two approaches serve different parts of the design space, and many wallet platforms support both.

This tool is for informational purposes only and does not constitute financial advice. Data is approximate and based on publicly available specifications, benchmarks, and documentation. Server resource requirements vary with hardware, Bitcoin blockchain size, and software versions. Always verify current figures against the relevant project documentation before provisioning infrastructure.