A closed metal mailbox with a single slot and a golden Bitcoin coin on its front, several letters of different sizes slipping in quietly, against a dark background with blurred orange and blue waves
AI-generated illustration (FLUX.1-schnell, generated locally) — does not represent real data.

Silent Payments in October 2026: Who Can Actually Receive, What Scanning Costs, and What BIP-352 Leaves Unsolved

NodeWitness Team 9 min read

BIP-352 lets you publish one static sp1 address and receive every payment at a different Taproot address that never links back to it. The mechanism has been stable since May 2024; what has moved since is wallet support, and what has not moved is Bitcoin Core.

Silent Payments is a static-address protocol, specified in BIP-352 [1], that removes receiver-side address reuse without any interaction between payer and payee. The sp1 address never appears on-chain; each payment lands at an ordinary Taproot output the sender derives on its own. The BIP is marked "Complete", version 1.0.0 was merged on May 8, 2024, and the current revision, 1.1.1, dates from April 16, 2026. This piece skips the tutorial you have probably already read on Optech or in a wallet's blog and covers the three things those rarely nail down: who can receive today, with a primary source per claim; what scanning costs and who bears it; and what a static address does nothing about.

Where it sits among the tools you already know

We have covered address reuse as the most common flag our audit raises, and the broader question of whether a wallet is traceable. Toxic consolidation is the failure mode Silent Payments explicitly leaves alone, and it comes back in the last section.

The gap BIP-352 fills is narrow and real: any address you have to publish — a donation page, a Nostr profile, a recurring invoice — is reused by construction, and HD wallets cannot help because the payer never asks you for a fresh one. The two earlier answers each failed that case for a different reason. Handing out an xpub, as the BIP's motivation section notes, reveals all your future addresses to whoever holds it. BIP-47 [2] payment codes require a notification transaction before the first payment, an output to your notification address plus 80 bytes in an OP_RETURN, paid by the sender and permanently public; the BIP-47 text itself acknowledges that this leaks the potential relationship between the two parties. BIP-352 replaces the notification with computation on the sender's side and scanning on the receiver's.

The mechanism, kept short

An sp1 address encodes two public keys of yours: a scan key and a spend key. The sender takes the private keys of the inputs it is about to spend, combines them with your scan key through an elliptic-curve Diffie-Hellman exchange, and uses the resulting shared secret to tweak your spend key into a fresh Taproot output. An extra hash over the transaction's smallest outpoint guarantees that a sender reusing the same input key still produces a different address every time. Eligible input types are P2TR, P2WPKH, P2SH-P2WPKH and P2PKH; multisig and script-path inputs are excluded, and the BIP recommends that all inputs in a transaction belong to one entity because the collaborative case has no formal security proof yet.

You recover the payment by running the same computation from your side: the input public keys are visible on-chain and you hold the scan private key, so for every transaction with at least one Taproot output and one eligible input you derive the candidate output and check for a match. That loop is the whole cost of the protocol.

Taproot outputs are SegWit version 1. How much of the network's traffic already uses SegWit (Taproot included, not broken out) is tracked on our SegWit adoption chart [19].

Flow diagram of a Silent Payment: the static sp1 address at the top, never written on-chain; the sender derives a unique Taproot address per payment from its own input keys; the receiver scans every block to find its outputs
Three payments to the same sp1 address produce three unrelated Taproot outputs on-chain. The sp1 address is never written anywhere; the receiver finds the outputs by scanning.

Scanning: who pays, and in what currency

The BIP says it plainly: the benefits "come at the cost of requiring wallets to scan the blockchain in order to detect payments", which is "generally feasible for full nodes but poses a challenge for light clients". A full node already holds every transaction; scanning is CPU time over data it has. A phone has none of it, so it has to choose between two costs.

Cost one is bandwidth. A server can hand the client the summed input public key of each eligible transaction, 33 bytes apiece, and BIP-158 compact block filters let the client skip blocks that cannot contain its outputs. The BIP's appendix puts that at 30-50 MB per month at today's Taproot usage and around 450 MB per month if every transaction were Taproot; it also notes that roughly 75% of transactions with Taproot outputs spend them fully within 150 blocks, which lets a client that scans every few days skip most of the history. Silentium, Louis Singer's proof-of-concept wallet, is built on this model against its own index server.

Cost two is trust. Frigate [3], the Electrum server Sparrow auto-selects for receiving, implements the remote-scanner approach: the client submits its scan private key, the server keeps it in RAM for the session and returns the client's transactions. A scan key cannot spend anything, but whoever runs that server learns which transactions are yours while you are connected. Frigate's README defends the design with the failure of cost one: a reasonable scan window needs "gigabytes of tweaks, filters and blocks" on the client, against the few megabytes a conventional Electrum wallet consumes.

Our own position is easy to state and easy to check. We run a full, unpruned Bitcoin Core node — the same fact that lets us compute HODL waves from the UTXO set — and Frigate ships self-hosting instructions. A full-node operator can make the "remote" scanner local, and the scan key never leaves the machine. That is an advantage for people already paying for a node, not a property the protocol hands out for free. And we would rather say so than imply otherwise.

Support status on October 8, 2026, one source per line

Every entry comes from the project's own release notes or repository, checked while writing. Anything that changes after this date is settled by the linked source, not by this text.

  • Cake Wallet: send and receive since v4.18.0, May 29, 2024 [4]. Its docs [5] describe scanning as opt-in from Settings, run on-device against a tweak-indexing Electrum server (Cake's own if the user's node lacks one), and warn that it takes time, battery and data.
  • Sparrow: send since 2.3.0, October 3, 2025 [6]; receive since 2.5.0, May 21, 2026 [7], airgapped signers included. Receiving requires an SP-capable Electrum server; the release adds a public one and auto-selects it when needed.
  • BlueWallet: send only, since v6.6.7, June 25, 2024 [8] ("ADD: send to SilentPayment address"). The receive request in its tracker (#7432 [9]) has been open since December 2024 with no maintainer response, and the team's own library marks receiving as a TODO.
  • Silentium: send and receive as a mobile-first web app; its repository [10] calls it "an experimental project acting as a proof of concept" and says to use it at your own risk.
  • Bitcoin Core: no wallet support in any release. The cryptography landed: the silentpayments module was merged into libsecp256k1 on July 22, 2026 [11], shipped in libsecp256k1 0.8.0 on August 3, and Core updated its vendored copy on September 9. Of the wallet PRs, #35301 [12] (base protocol) was merged into master on September 23, 2026, after 32.0 branched off for its release candidates, so it does not ship in 32.0; #35302 [13] (sending) and #32966 [14] (receiving, draft) are still open. The light-client index PR (#28241 [15]) was closed unmerged, and neither the 30.0, 31.0 and 31.1 release notes nor the 32.0 draft notes [16] mention Silent Payments. The tracking issue is #28536 [17].

The community list at silentpayments.xyz [18] adds BitBox, Nunchuk and Wasabi as send-only and BlindBit and Dana as send-and-receive. We did not verify those against their release notes: secondary reference, not our claim.

What it fixes, what it does not

Problem BIP-352 Why
Reuse of a published address Fixed Every payment lands at a distinct Taproot output; sp1 never hits the chain
Donors linked to each other by a shared destination Fixed Nothing on-chain ties two payments to the same sp1
On-chain notification before paying (BIP-47) Removed The sender derives the address from data it already holds
Visible amounts Untouched Values stay public
Sender's common-input heuristic Untouched The payer's inputs are as attributable as in any transaction
Consolidating what you received Untouched Spending outputs together merges them exactly as before
Payer anonymity Untouched Not a mixer, not a coinjoin

Read the table as a scope statement. BIP-352 solves the receiver-side publishing problem completely and leaves everything else exactly where it was. Ten donations at ten different addresses, spent together in one transaction, collapse back into one owner under the common-input heuristic; the protocol cannot protect you from your own later spending. The payer gains nothing: anyone with its inputs labeled knows who paid, even if they cannot tell to whom. And the labels feature carries its own caveat, stated in the BIP: all labeled addresses share one scan key, so anyone who knows your sp1 address can recognize them as yours, which is why the text says labels "are not meant as a way for Bob to manage separate identities".

Sources

Labelled by type.

  1. Bitcoin BIPs, BIP-352. (Primary, specification)
  2. Bitcoin BIPs, BIP-47. (Primary, specification)
  3. Sparrow Wallet, Frigate. (Primary, project repository)
  4. Cake Wallet, v4.18.0, May 29, 2024. (Primary, project repository)
  5. Cake Wallet, docs. (Primary, vendor documentation)
  6. Sparrow Wallet, 2.3.0, October 3, 2025. (Primary, project repository)
  7. Sparrow Wallet, 2.5.0, May 21, 2026. (Primary, project repository)
  8. BlueWallet, v6.6.7, June 25, 2024. (Primary, project repository)
  9. BlueWallet, #7432. (Primary, project repository)
  10. Silentium (louisinger), repository. (Primary, project repository)
  11. Bitcoin Core, July 22, 2026. (Primary, official repository)
  12. Bitcoin Core, #35301. (Primary, official repository)
  13. Bitcoin Core, #35302. (Primary, official repository)
  14. Bitcoin Core, #32966. (Primary, official repository)
  15. Bitcoin Core, #28241. (Primary, official repository)
  16. Bitcoin Core, 32.0 draft notes. (Primary, official repository)
  17. Bitcoin Core, #28536. (Primary, official repository)
  18. silentpayments.xyz, silentpayments.xyz. (Secondary, explainer site)
  19. NodeWitness, our own data, verifiable on SegWit adoption chart. (Primary, own data)

The reuse problem an sp1 address prevents is one you may already have. Paste any address of yours into the privacy audit and it will tell you whether it has received repeat payments from the same source, with the arithmetic behind each flag in the open and no key requested.

More in Privacy and self-custody

See all 16 articles in Privacy and self-custody →

Last updated: October 15, 2026