Using Compact Block Filters on Mobile Wallets
This article will get into the details and tradeoffs of using a Compact Block Filter client for mobile bitcoin wallets, particularly as compared to the currently more standard Esplora/Electrum approach.
It’s a good article to start building a good mental model for this from a user perspective, or to bring to your local meetup for discussion.
tldr;
Here’s the gist of the tradeoffs of CBF vs using a public Electrum/Esplora server:
+1 CBF Superb privacy. You don’t reveal your addresses to a server you don’t know and shouldn’t trust.
+1 CBF When new blocks come in, you’re notified instantly. There is no need to constantly loop + query the Electrum server.
+1 Electrum: Less bandwith requirements when using Electrum (CBF needs to query for and download filters and some blocks).
+1 Electrum: You can query the server for transactions that pertain to your wallet that are in the mempool (CBF can only tell you about transactions that have been included in blocks).
Honestly some of the bandwith and storage requirements differences can be important in certain situations, but on modern phones with good connections, the real trade can be summarized as such:
Superb transaction privacy (CBF) at the cost of not seeing the mempool (your wallet only picks up on transactions that have been mined.)
More details and considerations
Resources
Using something like an Electrum client for syncing where the wallet loops over a short amount of time and queries the server uses a small amount of ongoing resources, even when not required (for example of no transactions are either incoming nor outgoing). On the other hand, a wallet using CBF will simply hear about new blocks from its peers, and will then decide if it needs to request the block or not.
Storage
The compact block filter client needs to store the chain of block headers. This requires storage of between almost nothing (on a new wallet) to about 20MB if the wallet was created at the SegWit activation block or later (2017), to about 75MB if the wallet is scanning from the genesis block.
Privacy
What’s special about a compact block filter node is that requesting the block filter from a full node doesn’t reveal anything about the addresses the wallet is interested in. If a filter is a match for one or more of the addresses/scripts the wallet is interested in, it can then request this block from a different peer, who will again know nothing about which transactions the wallet is interested in from the block.
Sync times
Time required for sync. A full, “from scratch” sync is potentially a longer process for a CBF node than if it simply used an Electrum server. This initial sync however, needs only be performed once (to scan all previous blocks and “catch up” to the latest block in the chain). All further syncs are simply about bridging the gap between the last block synced to the current latest block. For example if you last opened your wallet a week ago, on opening up the wallet will then sync up with peers and download block headers and filters for the past week, decide if any of those trigger a match, and download the appropriate blocks. In the case where there are no matches, this will happen over a few seconds and barely be noticeable. Furthermore this approach can be optimized by allowing the wallet to register a background task that runs once a day in the night or under other requirements (the phone be plugging into power, or on wifi instead of data, etc.). If such a task is performed once a day, a simple sync can then be completed in under a second, unnoticed by the user.
Mempool
The bigger downside of using CBF as your syncing mechanism for mobile wallet is probably the lack of mempool data. Because filters can only be calculated on blocks, peers cannot serve a filter to your wallet for the transactions that are in their mempool. This means the mobile wallet cannot “learn” about transactions that have just been broadcast and are in the mempool if they are using CBF, whereas they would if they instead query an Electrum or Esplora server. Depending on the target user experience for the wallet, this may or may not be a big deal. For example, a wallet offering both options could educate its users about this tradeoff (complete privacy vs mempool data access), and the users can then make an informed decision that would then not impact them negatively (users who care about privacy and don’t have access to a personal Electrum server would maybe prefer the CBF option and be fine with the no-mempool trade, whereas users who already have a home server with a running Electrum instance don’t need the extra privacy features and would prefer to see transactions instantly when they arrive in the mempool).