Silent Payments Bitcoin: Complete Guide

What Are Silent Payments?

Silent Payments (BIP352) solve one of Bitcoin’s oldest privacy problems: address reuse. Today, if you post a Bitcoin address publicly — for donations, on a website, or in a social media profile — anyone who sends to that address creates a publicly visible link between themselves and you. And every payment to the same address is trivially connected by blockchain observers.

Silent Payments let you publish a single static address that generates a unique on-chain address for every payment received. Each sender derives a fresh address using a combination of the recipient’s public key and the sender’s transaction inputs. The result is that no two payments ever go to the same on-chain address, and no outside observer can determine that two payments were sent to the same recipient — all without any interaction between sender and receiver.

Three people pay an address posted on your website. With an ordinary bc1q address, all three payments land at that same address on the chain, so anyone can see each payment and the 0.062 BTC total. With a silent payment address starting sp1q, each payer's wallet creates a different Taproot address, so the chain shows three unrelated addresses and an onlooker cannot tell that they are yours. — **One address to share, a fresh address for every payment.** The sp1q address itself never appears on the chain. Each payer’s wallet turns it into a new Taproot address that an onlooker cannot link back to you.

The Address Reuse Problem

Bitcoin best practice has always been: never reuse addresses. Each receiving address should be used exactly once. This is why wallets generate new addresses for every transaction.

But this creates a usability problem. If you want to receive bitcoin without interacting with the sender in real time, you need to either:

Publish a static address (which means everyone sends to the same address, destroying privacy).
Run a server that generates unique addresses for each sender (complex infrastructure).
Use an extended public key (XPUB), which reveals your entire transaction history to anyone who has it.

Silent Payments eliminate this trade-off. One static “address” (actually a pair of public keys) enables unlimited unique on-chain payments without server infrastructure, without sender-receiver interaction, and without revealing your transaction graph. For an overview of Bitcoin’s broader privacy landscape, the advanced privacy strategies guide provides context.

How Silent Payments Work (BIP352)

The Cryptography

A Silent Payment address consists of two public keys: a scan key and a spend key. The address is encoded in a format starting with sp1q (silent payments, version 0) and is much longer than a standard Bitcoin address: 116 characters, against 62 for a Taproot address.

A silent payment address drawn to scale: sp1q (silent payment, version 0), then your scan public key and your spend public key, 33 bytes each, then a checksum: 116 characters in all, against 62 for a Taproot address drawn below at the same scale. The scan key finds payments: whoever holds its private half can see payments to you but cannot spend them. The spend key moves the coins; scanning never needs it, so its private half can stay offline until you spend. Both come from your seed phrase. — **An sp1q address is two public keys, each with its own job.** The scan key lets a wallet find your payments; only the spend key can move them. Carrying two keys is why the address is almost twice as long as a Taproot address.

When a sender wants to pay you:

They take the private keys of the single-key inputs they are spending (for Taproot, the output key) and add them up.
They perform an Elliptic Curve Diffie-Hellman (ECDH) operation between that sum and your scan public key.
The result is a shared secret known only to the sender (from their private key) and the recipient (from the scan private key).
This shared secret is used to derive a unique output public key.
The sender creates an output paying to the derived address.

When you scan the blockchain for incoming payments:

For each transaction, you use your scan private key and the transaction’s input public keys to compute the same shared secret.
You derive the same output public key.
If the transaction has an output matching this derived address, the payment is yours.
You use your spend private key combined with the shared secret to spend from this address.

Two columns. The sender's wallet combines the private keys of the coins it is spending (a) with your scan public key from your sp1q address (B). Your wallet combines your scan private key (b) with the public keys of those same coins (A), which it sees in the transaction. Both reach the same shared secret, because a times B equals b times A (elliptic-curve Diffie-Hellman), and nobody else can work it out. The secret plus your spend public key gives a new Taproot address that only you can spend. — **Two wallets, opposite halves, one secret.** It takes either the sender’s private keys or your scan private key, so no one else can follow. A reference to one of the coins being spent is hashed in too, and a coin can be spent only once, so no two payments produce the same address.

The Key Properties

No address reuse: Every payment creates a unique on-chain address. Two senders paying the same Silent Payment address produce two different output addresses.
No interaction required: The sender derives the unique address independently. The recipient does not need to be online or provide a fresh address.
Unlinkable payments: An observer who sees your Silent Payment address published on your website cannot identify which on-chain outputs belong to you (without your scan private key).
Sender-side computation: The sender’s wallet does the cryptographic work. Recipients just scan.

How Silent Payments Differ From Stealth Addresses

Stealth addresses were proposed years before Silent Payments (notably in BIP47 / PayNyms and various stealth address schemes). They solve a similar problem but with different trade-offs.

BIP47 (Reusable Payment Codes / PayNyms)

BIP47 requires a notification transaction — a one-time on-chain transaction that tells the recipient “I want to pay you.” After this notification, both parties can derive shared addresses. The problems:

The notification transaction is publicly visible and links the sender to the recipient’s payment code.
It costs an on-chain transaction before any actual payment can happen.
The notification output can be identified by pattern, allowing blockchain analysts to map relationships.

Silent Payments Improvements

No notification transaction. The sender derives the unique address without any prior on-chain setup. There is no identifiable on-chain pattern.
Uses transaction inputs. Instead of requiring a separate notification, Silent Payments leverage the keys already present in the sender’s transaction inputs. This means the privacy enhancement has no additional on-chain footprint.
Better privacy for the sender. With BIP47, a notification transaction reveals who you intend to pay. With Silent Payments, there is nothing linking the sender’s address to the recipient’s identity.

With a BIP47 payment code, a new sender first broadcasts a notification transaction: a tiny amount to your notification address, a data output carrying the sender's payment code in a form only you can read, and the sender's change. Anyone who knows your payment code can spot it, and the coins that paid for it. Only then come payments to new addresses for you. With a silent payment there is no notification, just the payment: a new Taproot address for you and the sender's change, looking like any other Taproot payment. — **BIP47 announces each new sender on the chain; silent payments don’t.** The notification costs an extra transaction and leaves a pattern analysts can find. A silent payment leaves only the payment.

Trade-Offs

Scanning cost: Silent Payments require the recipient’s wallet to check every candidate transaction in each new block to detect incoming payments (see Scanning Overhead below). This is computationally expensive for full nodes but manageable with optimizations (light client filters, server-assisted scanning).
No SPV support currently: Light wallets cannot efficiently detect Silent Payments without additional infrastructure. BIP47 works with light wallets since the notification transaction is identifiable.
Longer addresses: Silent Payment addresses are 116 characters, compared with 62 for a Taproot (bc1p) address and 42 for a common bc1q address. QR codes handle this without issues, but manual transcription is impractical.

Wallet Support Status

Silent Payments are still early in adoption, but support has grown meaningfully through 2025 and into 2026. Checked on 7 November 2026 against the community-maintained wallet-support tracker at silentpayments.xyz and each project’s own release notes, the implementation landscape is:

Wallets with Silent Payment Support

Sparrow Wallet — Full support for both sending and receiving. Sending to sp1 addresses landed in v2.3.0 (October 2025); receiving Silent Payment wallets landed in v2.5.0 (May 2026), ready for airgapped hardware-wallet signers once their firmware supports it (see Hardware Wallet Compatibility below). This makes Sparrow the most complete desktop implementation. Its receiving wallets scan on a Frigate server, which receives your scan key and can therefore see your incoming payments (not spend them). On Sparrow’s public-server setting that is a public Frigate server, so run your own if you don’t want a third party to see what you receive.
Cake Wallet — One of the first mobile wallets to implement Silent Payments, supporting both sending and receiving. It performs on-device scanning (rather than offloading detection to a server), which costs more sync time and battery but keeps the server from learning which outputs are yours. Available on iOS and Android.
BlueWallet — Supports sending to Silent Payment addresses (since v6.6.7, June 2024); receiving is not built yet. Mobile, iOS and Android.
Nunchuk — Supports sending to Silent Payment addresses (added in March 2026), not receiving.

Wallets In Development

Bitcoin Core — No released version of Bitcoin Core ships a Silent Payments wallet. The BIP352 cryptography was merged into the libsecp256k1 library in July 2026 and the base BIP352 code into Bitcoin Core’s development branch in September 2026, but sending (#35302) and receiving (#32966) were still open pull requests as of November 2026. Do not expect a Silent Payments wallet in any current Bitcoin Core release — track the BIP352 tracking issue for status.
Wasabi Wallet — Supports sending to Silent Payment addresses from software wallets (it is disabled for hardware-wallet accounts since v2.7.2); generating and receiving Silent Payments is planned but not yet shipped.
Electrum — Its maintainers chose not to add Silent Payments to Electrum itself (they closed the pull requests in March 2026). An independent, unaudited plugin can send from standard single-signature software wallets on Electrum 4.6.0 or later, but use the latest release (4.7.2 fixed a flaw in how plugins are authorised). Electrum warns that third-party plugins have access to your wallet, so verify the plugin’s release hash and test it on testnet before a small first payment.

Hardware Wallet Compatibility

Silent Payments require the sender’s wallet to perform additional computation, and that computation needs the private keys of the coins being spent. When those keys live on a hardware wallet, the device itself must support Silent Payments: it computes its part of the shared secret, plus a proof the software wallet can check (BIP375 defines how this travels in a PSBT). Without that support the device cannot pay an sp1 address. BitBox02 added sending in firmware 9.21.0 (September 2024). On a BitBox02 or BitBox02 Nova, use 9.26.5 or later: from 9.21.0 to 9.26.4, a compromised computer or phone could lock a silent payment to an unintended address (BitBox says it could not steal funds directly; see our BitBox02 advisory). For Coldcard, Foundation Passport, Krux and SeedSigner, support was still in open pull requests as of November 2026.

Receiving splits the work the other way: the software wallet holds the scan key and finds payments, while the spend key can stay on the signing device, which must be able to sign for these outputs (BIP376 defines the PSBT fields). Sparrow has supported this since v2.5.0, but as of November 2026 the community tracker lists no released hardware-wallet firmware that can spend a received Silent Payment; support is in development for Coldcard, Krux and SeedSigner. Until your device supports it, a wallet that receives Silent Payments keeps its spend key in software, so treat it as a hot wallet and move larger amounts to cold storage.

Practical Usage Scenarios

Donations and Tips

The most natural use case. A content creator publishes their sp1... address on their website or social media. Every supporter who sends bitcoin creates a unique on-chain address. An observer cannot determine how many donations were received or the total amount without the creator’s scan key. Spending several donations in one transaction gives part of that away: it shows they share an owner, and each donor knows which output was theirs.

Compare this to the current donation model: a static Bitcoin address reveals the total donation volume, the timing of every donation, and potentially links donors to each other through chain analysis.

Business Payments

A freelancer or business can publish a Silent Payment address for invoicing. Clients pay to the same published address, but each payment lands at a unique on-chain address. The business’s total revenue and customer relationships are not visible on the blockchain, as long as it does not spend several of those payments in one transaction.

Personal Privacy

When giving your Bitcoin address to friends, family, or merchants, a Silent Payment address prevents these relationships from being mapped. Each person’s payment creates an independent on-chain address with no visible connection to the others, until you spend several of them in one transaction.

Complementing CoinJoin

Silent Payments and CoinJoin address different privacy dimensions. CoinJoin breaks the link between sender and source of funds; Silent Payments break the link between receiver and on-chain address. Used together, both the sender and receiver gain privacy: the sender’s transaction origin is obscured by CoinJoin, and the receiver’s identity is protected by Silent Payments.

Note on CoinJoin tooling (checked November 2026): the two most prominent CoinJoin services of the previous era are no longer operating as before. Samourai Wallet’s Whirlpool service is defunct: Samourai’s servers and domain were seized and its founders charged in April 2024 (later sentenced), and its Whirlpool coordinator no longer runs. An independent project, Ashigaru, has since revived the Whirlpool design on new infrastructure; it is not the seized service. Separately, zkSNACKs shut down the official Wasabi Wallet CoinJoin coordinator on 1 June 2024; Wasabi CoinJoin now depends on independent third-party coordinators. If you intend to combine CoinJoin with Silent Payments, verify the current state of any coordinator you plan to use before committing funds. The CoinJoin lesson covers which tools still work and what each one asks you to trust.

Limitations and Challenges

Scanning Overhead

The recipient must scan the blockchain to detect incoming payments. For a full node, this means performing an ECDH computation for every candidate transaction in every block: those with at least one Taproot output and a single-key input. Optimizations exist, such as tweak indices, but the computational cost is non-trivial. Light wallets rely on a server for part of the work, and how much that server learns depends on the wallet.

Finding payments takes four steps: take each new block, keep the transactions that have a Taproot output and a single-key input, do one shared-secret calculation for each with your scan key, and when an output matches, that payment is yours. Three ways to do the checking: your own full node does it all and nothing leaves your home; your phone downloads the same data as everyone else, 33 bytes per candidate transaction, and does the matching itself, at a cost in data and battery; or a server holding your scan key does it, quick and light, but it sees every payment you receive, though it cannot spend them. — **Someone has to check every candidate transaction.** Your own node keeps it all private; a phone can do the matching with a server’s help; handing your scan key to a server is easiest but lets it see what you receive.

Sender Requirements

The sender’s wallet must support Silent Payments. If you publish a Silent Payment address and a sender uses a wallet without SP support, they cannot pay you. This chicken-and-egg problem limits adoption in the short term. During the transition period, it is practical to publish both a standard receiving address (for wallets without SP support) and a Silent Payment address.

Change Address Handling

The sender’s wallet must be careful with change outputs. If the change address is linked to the sender’s identity (as it often is), the privacy benefit is primarily for the receiver. Full privacy requires the sender to also manage their UTXO hygiene carefully.

No Testable Address Before First Payment

Because the on-chain address is derived at send time, you cannot “look up” a Silent Payment address on a block explorer to verify it. Your wallet checks the encoding (the sp1 prefix, the length and the Bech32m checksum), which catches typos but not a swapped address. To know it belongs to the intended recipient, compare the whole address with one they gave you through a channel you trust. If you send a small test amount first, wait for the recipient to confirm their wallet found it.

How to Get Started

As a Receiver

Install a wallet that supports receiving Silent Payments — e.g. Sparrow Wallet (v2.5.0+) or Cake Wallet. (Bitcoin Core does not yet ship a Silent Payments wallet; see Wallet Support Status above.)
Generate your Silent Payment address. The wallet creates the scan and spend key pair automatically.
Back up the underlying keys (the wallet’s seed phrase typically derives both the scan and spend keys) and note the date you created the wallet: a restore finds payments only from the date it starts scanning.
Publish your sp1... address wherever you currently share a Bitcoin address.
Keep the wallet running (or sync periodically) to scan for incoming payments.

As a Sender

Use a wallet with Silent Payment sending support (e.g. Sparrow v2.3.0+, Cake Wallet, BlueWallet, Nunchuk or Wasabi).
Paste the recipient’s sp1... address into the send field.
The wallet automatically derives the unique on-chain address.
Confirm and broadcast as usual.

From the sender’s perspective, the process is nearly identical to sending to a normal address. The wallet handles the cryptographic derivation transparently.

Silent Payments and the Future of Bitcoin Privacy

Silent Payments represent a significant step toward making Bitcoin privacy the default rather than a deliberate, opt-in choice. Unlike CoinJoin, which requires active participation and specific transaction structures, Silent Payments work as a passive improvement — publish a better address format and privacy improves automatically with every payment received.

The combination of Silent Payments for receiver privacy, CoinJoin for sender privacy, and Taproot for reducing on-chain fingerprints moves Bitcoin toward a state where basic financial privacy does not require expert knowledge or specialized tools. It still requires wallet software adoption, but the trajectory is clear.

Frequently Asked Questions

Are Silent Payments a soft fork?

No. Silent Payments do not require any changes to Bitcoin’s consensus rules. They work entirely at the wallet level. The on-chain output of a Silent Payment is a standard Pay-to-Taproot (P2TR) output. No nodes need to upgrade for Silent Payments to work.

Can Silent Payments be used with multisig?

BIP352 defines Silent Payments for single-key recipients. Extending the scheme to multisig is theoretically possible but adds complexity around key aggregation and scanning. Research is ongoing, but practical multisig integration is not yet available. Sending has a limit too: only single-key coins (Taproot, P2WPKH, nested P2WPKH and legacy P2PKH) count towards the shared secret, so a wallet whose coins all sit in a classic multisig script cannot pay an sp1 address.

How much larger are Silent Payment addresses?

A Taproot (P2TR) address, encoded in bech32m, is always 62 characters. A Silent Payment address is 116 characters. This is manageable as a QR code but impractical to copy manually. In practice, Silent Payment addresses will be shared via QR code, copy-paste, or NFC — similar to how LNURL and Lightning addresses are shared today.

Do Silent Payments work with Lightning Network?

Not directly. Silent Payments are an on-chain mechanism. Lightning payments use a completely different privacy model (onion routing). However, you could use a Silent Payment address to receive on-chain bitcoin and then open a Lightning channel with those funds, combining on-chain receiver privacy with Lightning’s payment privacy.

Can I still receive from wallets that do not support Silent Payments?

No. The sender’s wallet must support the Silent Payment protocol to derive the unique address. If a sender’s wallet does not support it, they cannot send to your sp1 address. During the adoption period, maintain a traditional receiving address as a fallback.

How do I back up a Silent Payment wallet?

Mostly the same way you back up any Bitcoin wallet — by securing the seed phrase. The scan and spend keys are derived from the seed through standard derivation paths, so restoring from seed restores Silent Payment capability. But a restored wallet finds payments only by rescanning the blockchain from a start date or block height, and payments from before that point stay hidden until a scan covers them. Note roughly when you created the wallet, and when you restore, give a start date earlier than your first payment. The rescan can take time depending on the wallet’s scanning implementation.

Part of our free Bitcoin course: This topic is covered in the Advanced Bitcoin Security & Privacy course.

Filed under: Bitcoin Privacy