Bitcoin is a public ledger. Every transaction ever made is visible to anyone who wants to look. That's a feature, not a bug — it's what makes Bitcoin verifiable and trustworthy. But it creates a real privacy problem when it comes to receiving payments.
This post explains what Silent Payments are, how they solve that problem, and links to a full step-by-step tutorial covering Sparrow Wallet, BlueWallet, and Cake Wallet.
The Problem: Address Reuse
Every time you receive Bitcoin, you share a Bitcoin address with the sender. Every time you send Bitcoin, the recipient sees your address too. If you keep reusing the same address — which is the path of least resistance for most people — your entire transaction history becomes associated with that single address.
Anyone who has your address can see every transaction you've ever made: who paid you, how much, and when. That's not just a privacy concern in theory. It has real-world implications for financial security.
The standard advice has always been to generate a new address for each transaction. Most wallets make this easy — you click "Receive" and get a fresh address. But this creates its own friction: you can't just post a static address publicly without immediately compromising your privacy. Every payment to that address is visible and linked.
The Solution: Silent Payments
Silent Payments solve this by giving you a single, static address you can share publicly or reuse freely — while ensuring every actual on-chain payment arrives at a brand new, unique Bitcoin address.
Here's how it works at a high level:
When a sender wants to pay you, their wallet takes their own UTXO public keys and combines them with a key derived from your Silent Payment address using a cryptographic process called ECDH (Elliptic Curve Diffie-Hellman). The result is a unique one-time Taproot address that only you can detect and spend from. No two senders can generate the same on-chain address, even if they're all paying the same Silent Payment address.
From the outside — on the blockchain — the payment looks like any ordinary Taproot transaction. There's nothing to indicate Silent Payments were involved, and there's no way to link the on-chain address back to your static Silent Payment address.
Your static Silent Payment address starts with sp1 and looks something like this:
But on-chain, the actual address receiving your funds looks like any other Taproot address:
Every payment to your Silent Payment address generates a completely different on-chain address. Nobody watching the blockchain can connect those payments to each other, or to you.
Key Benefits
- No address reuse — the core privacy problem is solved by design. Even if a thousand people pay your static address, each payment lands at a distinct on-chain address.
- Better sender privacy too — because the on-chain address is derived from the sender's UTXOs, receivers can't link multiple sends from the same sender together.
- Simpler user experience — one address to share, forever. No need to generate and communicate a new address for every interaction.
The Trade-Off: Scanning
Silent Payments come with one meaningful trade-off: your wallet can't simply watch a list of addresses for incoming funds the way a standard Bitcoin wallet can. Because the on-chain address is derived from the sender's inputs — not pre-generated by you — your wallet has to actively scan the blockchain to detect payments intended for you.
This scanning process requires connecting to a server that indexes the necessary data. Most standard Bitcoin nodes and Electrum servers don't support this by default. As a result, you currently need to connect to a dedicated Silent Payments-compatible server. It's a temporary limitation as the ecosystem matures, but it's worth understanding before you get started.
Where Silent Payments Stand Today
Silent Payments were proposed by Ruben Somsen in 2022 and have been gaining wallet support steadily since. As of now, support is still limited:
- Sparrow Wallet supports both sending and receiving
- Cake Wallet supports both sending and receiving
- BlueWallet supports sending only (not receiving)
More wallets are expected to adopt the standard over time. The underlying protocol is solid — the bottleneck is implementation, not the idea itself.
Full Tutorial: Sparrow, BlueWallet & Cake Wallet
If you want to see exactly how to set up and use Silent Payments in practice, I've put together a complete video tutorial walking through the entire process.
Here's what's covered:
- Setting up a Silent Payments wallet in Sparrow — How to create a new wallet with the Silent Payments policy type selected, generate a seed phrase, and understand how the wallet structure differs from a standard Sparrow wallet — including the different derivation path and the
SP Scanfield where you'd normally see an xpub. - Connecting to the Silent Payments server — Why you need to switch away from a standard Bitcoin node, how to find the correct public server within Sparrow's settings, and what the privacy implications are of connecting to a third-party server.
- Receiving a Silent Payment from BlueWallet — A live demonstration of sending Bitcoin from BlueWallet to the Sparrow Silent Payment address, and how to verify that the funds arrive at a fresh Taproot address — not the static
sp1address itself. - Proving the privacy works: multiple payments, multiple addresses — Two additional payments are sent to the exact same static Silent Payment address — one from a second Sparrow wallet and one from Cake Wallet. The tutorial shows that each payment arrives at a completely different on-chain address, even though all three used the same static address. This is the core of what Silent Payments deliver.
- Receiving Silent Payments in Cake Wallet — How to switch Cake Wallet to Silent Payments receive mode, how to trigger a blockchain rescan from a specific date, and what to expect while the wallet scans for incoming payments.
- Sending from Sparrow to a Cake Wallet Silent Payment address — How to scan a Silent Payment QR code inside Sparrow, and a quirk in Cake Wallet's address export format that you'll want to know about before you try this yourself.
- Sending from a Silent Payments wallet to a normal Bitcoin address — Silent Payments wallets aren't restricted to paying other Silent Payment addresses. The tutorial shows a standard send from the Silent Payments wallet to an ordinary Bitcoin address — no issues.
Should You Be Using Silent Payments?
It depends on your situation — and for most people running their own node, the honest answer right now is probably not yet.
If you're already connected to your own Bitcoin node and generating a new address for every transaction, you're doing the right thing. Silent Payments don't improve on that setup at the moment — and switching to a public server to support them would actually be a step backwards for your privacy.
Where Silent Payments make more sense is for specific use cases: accepting donations, posting a public tip address, or receiving regular DCA purchases where you want a static address without the privacy cost of address reuse. In those situations, the trade-off is more justified.
The underlying technology is solid and the privacy model is genuinely good. But the infrastructure isn't there yet. Until you can run Silent Payments scanning on your own node without relying on a third-party server, the recommendation is to use them selectively rather than as your default receive setup.
If you need help with your Bitcoin security setup — hardware wallets, seed phrase storage, multisig, or anything else — I offer one-on-one consulting. thebitcoincourse.com/consulting