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.

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 sp1 and is significantly longer than a standard Bitcoin address — around 117 characters.

When a sender wants to pay you:

1. They take the input keys from their transaction (the keys used to sign the inputs they are spending).
2. They perform an Elliptic Curve Diffie-Hellman (ECDH) operation between their input keys and your scan public key.
3. The result is a shared secret known only to the sender (from their private key) and the recipient (from the scan private key).
4. This shared secret is used to derive a unique output public key.
5. The sender creates an output paying to the derived address.

When you scan the blockchain for incoming payments:

1. For each transaction, you use your scan private key and the transaction’s input public keys to compute the same shared secret.
2. You derive the same output public key.
3. If the transaction has an output matching this derived address, the payment is yours.
4. You use your spend private key combined with the shared secret to spend from this 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.

Trade-Offs

• Scanning cost: Silent Payments require the recipient to scan every transaction on the blockchain to detect incoming payments. 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 roughly 117 characters, compared to ~62 for standard bech32 addresses. QR codes handle this without issues, but manual transcription is impractical.

Wallet Support Status

Silent Payments are still early in adoption. As of early 2026, the implementation landscape:

Wallets with Silent Payment Support

• Bitcoin Core — Merged support for Silent Payments receiving and sending. Available in Bitcoin Core 28.0+. Command-line interface primarily.
• Cake Wallet — One of the first mobile wallets to implement Silent Payments. Available on iOS and Android.
• Silentium — A dedicated Silent Payments wallet focused specifically on this feature.
• BlueWallet — Support added in recent versions for both sending and receiving.

Wallets Considering or Developing Support

• Sparrow Wallet — Discussion and development ongoing. Sparrow’s architecture as a full-featured desktop wallet makes it a natural fit.
• Electrum — Community interest but no confirmed timeline.

Hardware Wallet Compatibility

Silent Payments require the sender’s wallet to perform additional computation. Hardware wallets can sign transactions that pay to Silent Payment addresses, but the address derivation must happen in the software wallet before the transaction is passed to the hardware device for signing. Receiving Silent Payments on a hardware wallet requires the associated software wallet to handle the scanning.

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.

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.

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.

Complementing CoinJoin

Silent Payments and CoinJoin address different privacy dimensions. CoinJoin (like Whirlpool) 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.

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 transaction in every block. Optimizations exist (tweak indices, pre-filtering by transaction type), but the computational cost is non-trivial. Light client solutions are still being developed.

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 is correct. You can validate the format (starts with sp1, correct length), but you cannot verify it points to the intended recipient without actually sending. Standard precautions apply: send a small test amount first.

How to Get Started

As a Receiver

1. Install a wallet with Silent Payment support (Bitcoin Core 28+, Cake Wallet, or Silentium).
2. Generate your Silent Payment address. The wallet creates the scan and spend key pair automatically.
3. Back up the underlying keys — the wallet’s seed phrase typically derives both the scan and spend keys.
4. Publish your sp1... address wherever you currently share a Bitcoin address.
5. Keep the wallet running (or sync periodically) to scan for incoming payments.

As a Sender

1. Use a wallet with Silent Payment sending support.
2. Paste the recipient’s sp1... address into the send field.
3. The wallet automatically derives the unique on-chain address.
4. 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.

How much larger are Silent Payment addresses?

A standard bech32m address (P2TR) is around 62 characters. A Silent Payment address is around 117 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?

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. Restoring from seed restores Silent Payment capability. However, after restoration, the wallet needs to rescan the blockchain to find historical payments, which can take time depending on the wallet’s scanning implementation.

For a broader perspective, explore our Bitcoin multisig guide guide.