Silent Payments on Mobile: Bandwidth Feasibility and the Indexer Trust Problem

Silent Payments promise a reusable Bitcoin address without exposing an obvious chain of payments to that address. A sender uses the recipient's public information to derive a fresh Taproot destination, and the recipient's wallet later scans eligible transactions to find the output that belongs to it.

That receiving scan has been the difficult part for phones. A September measurement project reports that BlindBit Oracle v2's complete scanning feed would require about 8 MB per day near the upper end of its dataset. The number suggests mobile bandwidth may be manageable. It also highlights a separate risk: a light wallet depends on an indexer to deliver complete scanning data, and an omitted entry can leave a real payment undiscovered.

The emerging tradeoff is therefore less about raw download size than about what a wallet can verify. The data can fit through a phone connection. The wallet still needs a reliable way to know that every relevant piece arrived.

What the measurements establish

The 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. The project reports that as 15.08 GB, averaging 59.0 KB per block. That full-history total describes a restore across the measured range.

The daily number 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. It 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.

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

BIP-352 defines the reusable address and the receiver's scan. 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.

A full node can derive that data from the blockchain. A light wallet needs another source. The work-in-progress index-server specification describes server-assisted models that move different amounts of work and information away from the device.

One model keeps matching on the phone and asks a server for public tweaks. That 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.

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.

The trust choice is already reaching wallets

The standards picture has two layers. BIP-352's status is Complete, which covers 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 WIP 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.

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.