Silent Payments Mobile Scanning Bandwidth Measured at 8 MB Daily, but Trust Risks Remain
A new measurement project indicates that the bandwidth required for mobile wallets to scan for Silent Payments may be manageable, averaging roughly 8 MB per day near the current chain tip. However, the research highlights a more critical challenge: light wallets depend on indexers to deliver complete scanning data, and a single omitted entry can leave a real payment undiscovered.
How Silent Payments Scanning Works
Silent Payments, defined in BIP-352, enable a reusable Bitcoin address without exposing an obvious chain of payments. A sender uses the recipient’s public information to derive a fresh Taproot destination. The recipient’s wallet must then scan eligible transactions to find the output belonging to it. For a full node, this data is derived directly from the blockchain. For a light wallet, another source—an indexer—is required.
Measurement Project Scope and Findings
The independent project processed every Bitcoin block from height 709,656 through 965,089, an inclusive span of 255,434 blocks from shortly after Taproot activation to September 2026. Its per-block CSV contains the same number of rows with those exact height boundaries.
Across that history, the complete BlindBit v2 scanning payload totaled 15,079,946,729 bytes, reported as 15.08 GB, averaging 59.0 KB per block. That full-history total describes a restore across the measured range. The daily figure answers a different question: using the average from heights 900,000 through 965,089 and an assumed 144 blocks per day, the project calculates about 8.0 MB for a wallet following the chain near the dataset’s upper end. This does not describe the initial historical download.
The repository was produced by one independent operator. Its data and scripts are public, and the aggregate row count and payload totals can be checked from the CSV, but a second operator has yet to publish a full rerun. The result speaks to bandwidth volume; it does not measure phone battery use, processor load, storage behavior, or delivery latency.
Filter-Based Alternative Modeled
The project also estimates a lighter filter route: about 0.94 GB of modeled Taproot-only filters plus roughly 6.2 GB of raw tweaks yields a 7.14 GB subtotal. The 15.08 GB complete feed is about 2.1 times that subtotal. The filter route then adds a full-block download for every match, including false positives, so its realized traffic varies by wallet activity and match rate.
The filter component is a model built from exact per-block item counts. Its sizing formula was checked against 21 real filter encodings and landed within about 0.5%, according to the project. A Taproot-only Silent Payments filter has yet to be deployed.
How an Indexer Can Make a Payment Invisible
For each eligible transaction, the wallet combines its private scan key with public data derived from the transaction’s inputs. It uses the result to generate candidate output keys and checks whether one appears in the transaction. One server-assisted model keeps matching on the phone and asks a server for public tweaks. This can avoid sharing the private scan key, but the server’s response still needs to be complete. If the one tweak needed for an incoming payment is absent, the wallet generates no matching destination and shows no receipt.
A Cake Wallet issue opened in July 2025 analyzed how the miss could persist. The reporter wrote that a client may save a later local scan height after receiving incomplete data. If the wallet then treats the earlier range as finished, connecting to a different server would not automatically make it ask for the missing block again. The issue page does not show a maintainer confirmation of that architecture analysis, and it does not document intentional withholding by any server.
The output itself remains valid on Bitcoin. The recipient’s keys still control it. Discovery can be recovered by rescanning from an earlier height against a complete, honest source or by using a full-node-backed scan. The user-facing danger is silence: the wallet may show a complete sync without signaling that historical data should be revisited.
Proposed Mitigation: Chained Commitments
The project proposes chained commitments to each block’s canonical tweak set. Two servers that publish commitments can be compared, and an externally anchored checkpoint can expose later rewriting or equivocation. This creates an audit trail. A first client relying on a single response can still receive an incomplete set before an independent comparison reveals the discrepancy.
Wallet Implementations Diverge on Trust Models
The standards picture has two layers. BIP-352’s status is Complete, covering the core Silent Payments protocol. Its light-client appendix still describes privacy-preserving phone support as open research. The new converged light-client document labels itself pre-draft v0.1, with adoption and interoperability work still ahead.
Wallet developers have meanwhile shipped different server relationships. Sparrow Wallet 2.5.0, released in May 2026, added Silent Payments receiving and automatic selection of a public Frigate server. Frigate describes its design as a Remote Scanner, which performs the matching on server infrastructure with ephemeral client scan keys.
The work-in-progress index specification maps Cake Esplora to Cake Wallet and lists Dana Wallet, BDK with Kyoto, and BlindBit Desktop as clients around BlindBit Oracle. Dana and Silentium describe their own mobile projects as experimental. Those implementation sources do not claim adoption of the September pre-draft.
User Choice Extends Beyond Synchronization Speed
For a user, these designs define more than synchronization speed. A remote scanner can learn which transactions belong to a wallet. A tweak server can keep the private matching work on the phone while leaving the wallet dependent on a complete feed. A personal full-node-backed service shifts both computation and trust onto infrastructure the user controls.
The measurements make the bandwidth part of that choice look less forbidding. Wider adoption still depends on a second property: a wallet must be able to detect incomplete history before an incoming payment disappears from its view. Silent Payments can hide address reuse on-chain, but phone wallets need safeguards that keep privacy from becoming a new form of server trust.