Bitcoin Silent Payments can hide incoming payments

Silent Payments lets a sender derive a fresh Taproot destination from a recipient’s public data while the recipient’s wallet later scans transactions to find matching outputs. A recent measurement of BlindBit Oracle v2 quantified the scanning data required for that flow and identified a failure mode in indexer-assisted setups that can leave valid payments unshown in light wallets.

The measurement project processed every Bitcoin block from height 709,656 through 965,089, an inclusive span of 255,434 blocks from shortly after Taproot activation through September 2026. Across that range the BlindBit v2 complete scanning payload totaled 15,079,946,729 bytes, reported as about 15.08 GB, with an average of 59.0 KB per block. Using the subset from block 900,000 through 965,089 and assuming 144 blocks per day, the project estimated roughly 8.0 MB per day for a wallet following the recent chain. The project noted that the daily figure differs from the size of an initial historical restore.

Silent Payments requires per-transaction data that full nodes can derive directly from the blockchain. Mobile and other light wallets commonly rely on external indexers or servers to deliver per-transaction public tweaks or matching data. In a server-assisted model a missing tweak means the wallet cannot generate a matching destination key and therefore will not display a receipt for an on-chain output.

The project also modeled a lighter route based on Taproot-only filters plus raw tweaks. That model totaled about 7.14 GB across the measured history, comprising roughly 0.94 GB for filters and about 6.2 GB for raw tweaks. The full BlindBit v2 feed is about 2.1 times larger than that subtotal. The filter approach requires a wallet to download any full block that a filter matches, so realized bandwidth can rise if filters produce many matches or false positives. A Taproot-only Silent Payments filter has not been deployed in production.

The dataset and analysis were published by a single independent operator; the data and scripts are publicly auditable. The project did not report a second operator rerun. The measurement focused on bandwidth volume and did not measure phone battery impact, processor load, storage patterns, or delivery latency.

BIP-352 defines the Silent Payments address format and the receiver-side scan. A work-in-progress index-server specification sets out server-assisted models that shift varying amounts of work off the device. One model supplies public tweaks while keeping the private scan key on the phone; that design relies on the server delivering a complete set of tweaks.

An issue opened on Cake Wallet in July 2025 described a scenario where an omitted tweak could remain hidden: a client might record a later local scan height after receiving incomplete data, and if the wallet treats the earlier range as complete, connecting to a different server would not automatically re-request the missing block. The on-chain output remains spendable and can be recovered by rescanning from an earlier height against a complete source or by using a full-node-backed scan, but users can be left with undiscovered payments until a rescan is performed.

Wallet implementations have taken different approaches to the server trust question. Sparrow Wallet 2.5.0, released in May 2026, added Silent Payments receiving and defaults to a public Remote Scanner that performs matching on server infrastructure with ephemeral client scan keys. The index specification maps Cake Esplora to Cake Wallet and lists other clients around BlindBit Oracle, including Dana Wallet, BDK with Kyoto, and BlindBit Desktop. BIP-352’s core protocol is marked Complete; light-client support and converged light-client guidance are in pre-draft and research stages.

The measurement project recommended safeguards to reduce indexer-trust risks, including chained commitments to each block’s canonical tweak set, publication of commitments from multiple servers for cross-checking, and an externally anchored checkpoint to detect rewritten or omitted entries. The project noted that a client relying on a single server response can receive incomplete data before independent comparison is possible. Running a personal full node or a full-node-backed service moves computation and trust under the user’s control.