Silent Payments: A nice Bitcoin privacy setup
One Address, a lot of Privacy opportunities
The problem
Every time you share a Bitcoin address, you leave a thread someone can pull (forever).
Share the same address twice and a chain analyst can link those two payments together. Do it a hundred times — like most people do when they paste their address into a profile, a donation page, or a checkout form — and you’ve handed over a near-complete financial map of your on-chain activity.
The standard advice has always been: generate a new address for every transaction. Good advice. Bad UX.
Silent Payments, formalized in BIP-0352, solve this at the cryptographical level. One static address, published once. Every payment that hits it lands at a fresh, unique on-chain address — automatically, without any coordination between you and the sender.
This is what privacy-preserving Bitcoin receiving actually looks like.
What Are Silent Payments?
Silent Payments are a method for receiving Bitcoin privately using a single, reusable static address that never directly appears on-chain.
When someone sends you a payment, the protocol derives a brand-new Taproot address for that specific transaction. An outside observer looking at the blockchain sees a normal Taproot output — they have no way to know it was generated from your silent payment address, or that it’s connected to any of your other received payments.
The receiver publishes one address. Every sender gets a unique destination. No interaction required between the two parties beyond sharing that address once.
Silent payment addresses on mainnet start with sp1q and are considerably longer than standard Bitcoin addresses — at minimum 117 characters. That length isn’t padding; it carries the cryptographic data that makes the whole system work.
How It Works Under the Hood
The magic behind Silent Payments is Elliptic-curve Diffie–Hellman (ECDH) — the same family of math that secures most encrypted communications on the internet today.
Here’s the simplified flow:
The sender takes the private keys from their transaction inputs and combines them with the receiver’s public keys (embedded in the silent payment address) to derive a shared secret.
That shared secret is used to “tweak” the receiver’s public key — producing a one-time destination address that didn’t exist before this transaction.
Only the sender and receiver can identify this address as belonging to the recipient. To everyone else on the blockchain, it looks like a standard Taproot output.
No round-trip communication. The math handles the coordination.
One important detail: Silent Payments require Taproot (P2TR) outputs for the privacy guarantees to hold. The protocol also supports deriving shared secrets from older input types — P2TR, P2WPKH, P2SH-P2WPKH, and P2PKH — but the destination output is always Taproot. If you’re not on Taproot, you’re not getting the full benefit.
The Dual-Key System: Scan and Spend
Most Bitcoin wallets collapse all key functions into one key hierarchy. Silent Payments deliberately separate two distinct roles:
Scan Key — used to monitor the blockchain and identify incoming payments. This key performs the ECDH computation needed to detect whether a given transaction is addressed to you. Because it cannot spend funds, it’s safe to keep on an internet-connected device — on your phone, on a hot wallet, on a server.
Spend Key — the key that actually authorizes moving funds. This one can stay in offline cold storage and only touch a signing device when you’re ready to send.
This separation is a meaningful security improvement over typical setups. Your watch-only capability is decoupled from your signing capability. A compromised hot device loses your privacy; it doesn’t lose your coins.
What Does It Look Like On-Chain?
This is where Silent Payments get genuinely elegant: nothing.
A silent payment transaction is indistinguishable from any other Taproot transaction to an outside observer. There’s no marker, no special output type, no metadata indicating that a silent payment address was involved. Chain analysts can’t filter for silent payment usage — there’s nothing to filter on.
Compare this to something like PayNym (BIP-47), which requires an on-chain notification transaction before the first payment. That notification is visible, linkable, and identifiable. Silent Payments have no equivalent. The protocol is fully stealth from the blockchain’s perspective.
Labels: One Address, Multiple Contexts
Silent Payments include a labeling system that lets you differentiate incoming payments without publishing multiple addresses.
Labels are incremental integers that modify the scan key in a deterministic way. You can give a different labeled address to different counterparties — a client, a donations page, an exchange withdrawal — and your wallet can tell them apart when scanning. But to an outside observer, all those labeled addresses look like unrelated Taproot outputs.
One specific label (m=0) is reserved for change outputs — allowing your wallet to identify its own change during recovery without relying on traditional BIP-32 derivation paths. This matters if you ever need to restore from a seed phrase with no additional metadata.
Wallet Support Right Now
Support is growing but still early. Here’s the current state:
Full support (send + receive):
Sparrow Wallet — the most complete desktop implementation. Create a “Silent Payment” wallet with the “Single Signature SP” policy type and Taproot script. Requires connecting to a server that indexes silent payment data.
Cake Wallet — mobile wallet with full send/receive support. Includes a feature to rescan the blockchain from a specific date to recover funds.
Nunchuk — has added support for the protocol.
Partial support (send only):
BlueWallet — can send to
sp1qaddresses but does not yet support receiving.
Hardware signing:
BitBox02 — has added hardware signing support for silent payment transactions.
A critical caveat: because a standard Bitcoin node doesn’t inherently know when a silent payment has arrived at your wallet, you need to connect to a specialized server that scans and indexes silent payment data. In Sparrow, this means pointing to a supporting Electrum server implementation. This is not a deal-breaker, but it’s friction that doesn’t exist with standard BIP-32 wallets.
The Light Client Problem
Here’s the main unsolved challenge: mobile wallets.
Full node scanning for silent payments is computationally expensive compared to traditional wallets. For each eligible transaction on-chain, your wallet must perform ECC multiplications to check whether that transaction is addressed to you. A full node can absorb this cost. A mobile client with limited bandwidth and battery cannot.
Two proposed solutions are currently in research:
Tweak Data indices — roughly 100 kB of additional data per block, allowing light clients to perform only the final derivation step rather than scanning raw transaction data.
BIP-158 block filters — compact client-side filters that help wallets identify potentially relevant transactions without downloading everything.
Neither is fully deployed and standardized yet. Until light client support matures, Silent Payments remain primarily a desktop/full node feature.
There’s also an open research question around CoinJoin compatibility. Silent payments can technically be used in collaborative transactions, but there’s no formal security proof that the combination is provably safe. Worth watching as the ecosystem develops.
Should You Use Silent Payments Today?
If you run Sparrow Wallet or Cake Wallet and you’re comfortable connecting to a specialized server: yes, absolutely. The privacy improvement for a public-facing address — a donation link, a business payment address, anything you publish — is significant and the UX is already solid.
If you’re primarily on mobile and relying on light clients: not yet. The infrastructure isn’t there. You’ll end up with a worse experience and potentially miss incoming payments if your scanning setup isn’t reliable.
The threat model that Silent Payments defend against is real and growing — KYC leaks, address reuse correlation, chain surveillance. Publishing a static Bitcoin address and expecting privacy from a regular P2TR or even a new-address-each-time workflow is increasingly fragile. BIP-0352 is the right direction.
So what?
Silent Payments don’t fix every privacy problem in Bitcoin. On-chain analysis, coinjoin research, Lightning channel fingerprinting — those are separate threat surfaces. But for the specific problem of receiving Bitcoin publicly without burning your financial privacy, BIP-0352 is the most elegant solution to date.
One address. Every payment unique. Nothing visible on-chain.
The wallet ecosystem is catching up fast. If you’re not already using Sparrow or Cake Wallet, now is a good time to get familiar with the setup — this will become the standard for privacy-conscious receiving in the next 12-24 months.