{"id":13273,"date":"2026-09-15T15:41:25","date_gmt":"2026-09-15T15:41:25","guid":{"rendered":"https:\/\/cryptonews.uk.com\/?p=13273"},"modified":"2026-09-15T15:41:25","modified_gmt":"2026-09-15T15:41:25","slug":"small-data-hidden-payment-risk","status":"publish","type":"post","link":"https:\/\/cryptonews.uk.com\/?p=13273","title":{"rendered":"small data, hidden payment risk"},"content":{"rendered":"

<\/p>\n

\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

What the measurements establish<\/h2>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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.<\/p>\n\n\n\n\n\n\n
Route<\/th>\nComparison basis<\/th>\nAdditional traffic<\/th>\n<\/tr>\n<\/thead>\n
BlindBit v2 complete feed<\/td>\n15.08 GB across the measured history; about 8 MB per day in the recent-era estimate<\/td>\nNo matched-block fetch during scanning<\/td>\n<\/tr>\n
Modeled Taproot filter plus tweaks<\/td>\nAbout 7.14 GB across the measured history<\/td>\nFull block for every filter match<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

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.<\/p>\n

\"Infographic\"Infographic
Infographic comparing a 15.08 GB complete Silent Payments scanning feed with a 7.14 GB filter-plus-tweaks subtotal, then showing how an omitted tweak can hide a payment until an earlier-height rescan with an honest source.<\/figcaption><\/figure>\n

How an indexer can make a payment invisible<\/h2>\n

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.<\/p>\n