Silent Payments

What Are Silent Payments?

Silent payments are a Bitcoin privacy protocol defined in BIP-352, authored by josibake, Ruben Somsen, and Sebastian Falbesoner. The protocol allows a recipient to publish a single static identifier (starting with sp1q...) that senders use to derive fresh, unique P2TR addresses for every payment. Because each derived output is a standard Taproot spend, silent payment transactions are indistinguishable from ordinary Taproot transactions on the blockchain.

The core problem silent payments solve is address reuse. When a content creator, charity, or open-source project publishes a single Bitcoin address for donations, every payment to that address is publicly linkable. Anyone can see the total amount received and trace connections between senders. Generating fresh addresses requires interaction: the recipient must be online to hand out new addresses. Silent payments eliminate that interaction while preserving privacy.

BIP-352 reached "Complete" status in May 2024 (v1.0.0), with the latest revision (v1.0.2) published in July 2025. A growing ecosystem of companion BIPs supports the protocol: BIP-375 defines PSBT sending with discrete-log equality proofs for hardware wallet compatibility, BIP-376 adds PSBTv2 fields for tweak data, and BIP-392 specifies output script descriptors for silent payments.

How It Works

Silent payments rely on ECDH: a cryptographic technique where two parties each contribute a keypair and derive the same shared secret without revealing their private keys. The sender uses information already present in the transaction (their input private keys) combined with the recipient's public scan key.

Recipient Key Setup

The recipient generates two keypairs at the BIP-352 derivation path:

• Scan keypair (b_scan / B_scan): used to detect incoming payments by deriving shared secrets
• Spend keypair (b_spend / B_spend): used to construct the spending key for received funds

The silent payment address encodes both public keys in Bech32m format. At 117 characters, silent payment addresses are significantly longer than standard Bitcoin addresses, making QR codes the practical sharing method.

Sending a Payment

1. The sender sums all eligible input private keys: a = a_1 + a_2 + ... + a_n
2. An input hash is computed from the smallest outpoint and the summed public key A. This prevents output reuse even when the sender reuses the same keys across transactions.
3. The sender computes the ECDH shared secret: ecdh_shared_secret = input_hash * a * B_scan
4. A tweak is derived: t_k = hash(serP(ecdh_shared_secret) || ser32(k)) where k is an output counter (starting at 0)
5. The one-time Taproot output key is: P_k = B_spend + t_k * G

# Simplified derivation (pseudocode)
input_hash = SHA256(smallest_outpoint || sum_input_pubkeys)
shared_secret = input_hash * sender_privkey_sum * B_scan
tweak = SHA256(shared_secret || output_index)
output_key = B_spend + tweak * G   # unique P2TR output

The result is a standard P2TR output. On-chain observers see nothing unusual: no special script, no OP_RETURN marker, no notification transaction.

Receiving and Scanning

The recipient mirrors the derivation using their scan private key. For every transaction with Taproot outputs and qualifying inputs (P2WPKH, P2TR, P2PKH, or P2SH-P2WPKH), the recipient:

1. Extracts and sums the input public keys to get A
2. Computes the same shared secret: ecdh_shared_secret = input_hash * b_scan * A
3. Derives candidate output keys and checks them against the transaction's actual outputs

If a candidate matches, the recipient can spend the output using b_spend + t_k as the private key.

Labels

Recipients can generate labeled silent payment addresses to distinguish payment sources (for example, per-customer addresses for merchants). A label modifies the spend public key: B_m = B_spend + hash(b_scan || m) * G, where m is a label integer. Each label produces a distinct address but requires only marginally more scanning work.

Silent Payments vs. BIP-47

Both BIP-47 payment codes and BIP-352 silent payments solve the same problem: reusable payment identifiers that produce unique on-chain addresses. The approaches differ in a fundamental trade-off between sender cost and receiver cost.

The key advantage of silent payments: eliminating the notification transaction removes both its fee cost and its on-chain fingerprint. With BIP-47, a blockchain analyst can identify notification transactions and infer a payment relationship between the sender and recipient. Silent payments leave no such trace. For a deeper comparison of Bitcoin privacy techniques, see the silent payments privacy analysis.

The Scanning Problem

The primary challenge with silent payments is receiver-side computation. Unlike an HD wallet that monitors a predefined set of addresses, a silent payment recipient must evaluate every eligible transaction on-chain. No third party can perform this scan without access to the recipient's scan private key, which preserves privacy but makes delegation difficult.

For wallet recovery, the problem is more acute. Standard HD wallets use an address gap limit to determine when scanning can stop. Silent payment wallets must rescan the entire chain from the wallet's creation date (the "birthday index"), recomputing the ECDH derivation for every eligible transaction.

Indexing Solutions

BIP-352 Appendix A outlines several approaches to reduce scanning cost for light clients:

• Indexing servers: full nodes build an index of 33-byte summed-and-tweaked public keys per eligible transaction. Clients download roughly 33 bytes per qualifying transaction (empirically 7 to 12 kB per block, or 30 to 50 MB per month at current transaction volumes).
• Transaction cut-through: clients skip historical transactions where all Taproot outputs have already been spent. Empirical data shows approximately 75% of eligible transactions have their non-dust Taproot outputs fully spent within 150 blocks.
• Birthday scanning: clients only process blocks from the wallet creation date forward, avoiding a full chain rescan.
• Compact block filters (BIP-158) can be combined with the public key index to further reduce bandwidth.

Use Cases

Donations and Public Fundraising

The most natural use case: a nonprofit, open-source project, or content creator publishes a single silent payment address. Every donor sends to the same identifier, but each payment creates a unique on-chain output. No donor can see how much others contributed, and the recipient's total balance is not publicly derivable.

Privacy-Preserving Commerce

Merchants can publish a silent payment address (with labels for different storefronts or products) and receive payments without exposing their entire transaction history. Combined with coin control on the sender's side, silent payments significantly reduce the information available to chain surveillance. For related privacy techniques, see the PayJoin privacy guide.

Recurring Payments Without Interaction

A payer can send multiple payments to the same silent payment address over time without needing the recipient to generate fresh invoices. Each payment derives a different output because the sender's UTXOs (and therefore input keys) change between transactions.

Wallet Support

As of mid-2026, silent payment support is growing across the Bitcoin wallet ecosystem:

• Full send and receive: Sparrow Wallet, BlueWallet, Wasabi Wallet, Nunchuk, and several newer wallets (BlindBit Desktop, Dana Wallet, Silentium)
• Receive only: Bitcoin Core (via CLI), Cake Wallet
• Hardware wallet sending: signing devices including BitBox02, Coldcard, and SeedSigner support constructing silent payment outputs via BIP-375 DLEQ proofs

Bitcoin Core's full BIP-352 implementation is being developed incrementally across multiple pull requests. Partial receiving support is available via the command line, with broader integration still in progress.

Why It Matters

Address reuse is one of the most common privacy failures in Bitcoin. Every time a user posts a static address on a website, social profile, or QR code, they create a permanent link between their identity and on-chain activity. Silent payments break this link without requiring the recipient to run a server or be online when payments arrive.

For self-custodial wallet builders, silent payments offer a path toward better default privacy. Rather than asking users to manage address rotation, wallets can present a single persistent identifier while deriving fresh addresses automatically. Layer-2 protocols like Spark can complement silent payments by handling frequent, low-value transfers off-chain while using on-chain silent payments for larger or less-frequent settlements. For more on how Bitcoin address types have evolved, see the address types guide.

Risks and Considerations

Computational Overhead

Scanning every eligible transaction requires one ECDH operation per transaction. On a full node this is manageable, but mobile devices and SPV clients may struggle with the bandwidth and computation required. Indexing solutions reduce this burden but introduce a dependency on the index provider, which must be trusted not to withhold data (though it cannot learn which payments belong to the recipient).

Sender Requirements

The sending wallet must support BIP-352 derivation. Unlike standard address formats where any wallet can send to any address, silent payment addresses require the sender's wallet to perform the ECDH calculation using its input private keys. This means the sender's wallet must be updated to support the protocol, and hardware wallets need BIP-375 DLEQ proof support to participate safely.

Wallet Recovery Complexity

Restoring a silent payment wallet from a seed phrase requires rescanning the blockchain from the wallet's birthday. There is no gap limit shortcut: the wallet must recompute ECDH for every eligible transaction since its creation. This can take significantly longer than restoring a standard HD wallet.

Input Type Limitations

Silent payments can only be derived from transactions with qualifying input types (P2PKH, P2WPKH, P2SH-P2WPKH, and P2TR). Transactions using non-standard input scripts or multi-party constructions like HTLCs may not expose the public keys needed for derivation, limiting the protocol's applicability in certain contexts.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.