Silent payments explained (BIP 352)

Silent payments (BIP 352) let you publish one static address, starting with sp1, that anyone can pay without the payments being linkable on-chain. The sender combines their own input keys with your public keys to compute a fresh Taproot output that only you can find and spend. There is no notification transaction and no interaction. The cost moves to the receiver, whose wallet has to scan the blockchain to detect incoming payments.

Updated 2026-10-20 · 8 min read

What are silent payments?

Silent payments are a way to receive bitcoin at a reusable address without the privacy problems of address reuse. BIP 352, by josibake, Ruben Somsen and Sebastian Falbesoner, describes them as "static payment addresses in Bitcoin without on-chain linkability of payments or a need for on-chain notifications".

You publish one address, for example on a website, an invoice template or a donation page. Each sender derives a different, unique Taproot output from it. To everyone else on the network these outputs look like any other Taproot payment, and nothing on-chain connects them to your address or to each other.

The problem: address reuse

Using a new address for every payment is one of the basic privacy practices in Bitcoin. If you post one ordinary address publicly, anyone can look it up and see every payment you received and every time you spent from it.

Fresh addresses avoid that, but they need interaction: you have to give each payer a new address, a batch of addresses, or an extended public key. BIP 352 points out that this "is often infeasible and in many cases undesirable". Think of a donation page, or a payment you want to receive while your wallet is offline.

Earlier protocols, such as BIP 47 payment codes, solved this with a reusable identifier plus a one-time notification transaction on the blockchain. BIP 352 lists the trade-offs of that approach: extra cost for one-time payments, a visible footprint on-chain that can reveal metadata, and the ability for the receiver to link every payment from the same sender. Silent payments remove the notification entirely.

How do silent payments work?

The key idea is Elliptic Curve Diffie-Hellman (ECDH): two parties can each combine their own private key with the other's public key and arrive at the same shared secret, without ever sending it.

1. The receiver publishes public keys inside a silent payment address.
2. The sender picks the inputs to fund the payment and adds up their private keys.
3. The sender computes a shared secret from that sum and the receiver's public scan key. The calculation also includes a hash of the smallest outpoint being spent, so that the same sender paying twice from the same key never produces the same output.
4. The sender derives the output key: the receiver's spend key, tweaked by a hash of the shared secret. It is encoded as a normal Taproot (P2TR) output.
5. The receiver scans. For each eligible transaction, the receiver's wallet adds up the input public keys, does the same ECDH calculation with its private scan key, and checks whether the expected output appears.
6. The receiver spends with its spend private key plus the same tweak.

Because all of the sender's inputs are summed, the receiver needs only one elliptic-curve multiplication per transaction, and doesn't learn which particular input belonged to the sender. A sender can also pay the same address several times in one transaction: each extra output adds a counter to the hash.

Scan key and spend key

A silent payment address contains two public keys:

• The scan key is needed online, to detect payments. A wallet that only has the scan private key can see incoming payments but cannot spend them.
• The spend key is needed to spend, and can stay in cold storage.

This split lets a watch-only machine do the scanning while the spending key lives on a hardware signer.

What does a silent payment address look like?

A silent payment address is a Bech32m string:

• The prefix is sp on mainnet and tsp on test networks such as testnet and signet.
• After the separator 1, the character q marks version 0, so mainnet addresses start with sp1q.
• The payload is 66 bytes: the 33-byte scan public key followed by the 33-byte spend public key.

That makes a version 0 address 116 characters long on mainnet (117 on testnets), much longer than a normal address. BIP 173 limits regular SegWit addresses to 90 characters, so BIP 352 suggests implementations accept up to 1,023 characters to leave room for future versions. Version 31 is reserved for a backward-incompatible change.

The address itself is never written to the blockchain. Only the derived Taproot outputs are.

Labels: telling payments apart

A receiver may want to know which payments came from which source, such as one address for a website and another for an invoice. Scanning for several separate addresses would multiply the work, so BIP 352 adds labels: an integer m tweaks the spend key, producing a different address that shares the same scan key. The wallet scans once and recognizes all of them.

Labels aren't separate identities. Every labelled address contains the same scan key, so anyone can see they belong to the same wallet. Label m = 0 is reserved for the wallet's own change, and the wallet must never hand it out.

Which transactions can pay a silent payment address?

The sender's inputs must expose public keys the receiver can read. BIP 352 uses these input types to compute the shared secret: P2TR, P2WPKH, P2SH-P2WPKH and P2PKH. A transaction can include other inputs, such as multisig, but they are ignored for the calculation. At least one eligible input is required.

Receivers only need to scan transactions that have at least one Taproot output and at least one eligible input, and that don't spend SegWit outputs of version 2 or higher. Receiving outputs are always Taproot, so the payment's address type is bc1p on-chain.

The cost: scanning

Silent payments shift work from the sender to the receiver. An ordinary wallet watches a list of known addresses; a silent payment wallet must check every eligible transaction in every new block, performing the ECDH calculation for each. BIP 352 describes this as "generally feasible for full nodes but poses a challenge for light clients".

Recovering a wallet from backup means scanning the chain from the wallet's birthday, which can take a while. That's one reason BIP 393 proposes a bh annotation for the block height to start scanning from, and an ml annotation for the highest label used.

Light clients

For phones and other light wallets, BIP 352 calls light client support "an area of open research" and sketches options in an appendix:

• Tweak data from a server. A full node or index server can precompute the summed input key for each eligible transaction, about 33 bytes per transaction, and serve it to light clients.
• Compact block filters. With that data, the client can use BIP 158 filters to check whether a block contains one of its outputs before downloading it.
• Optional out-of-band notifications from the sender. The receiver can always ignore them and scan instead.

Silent payments vs BIP 47 payment codes

Both aim to give you a reusable identifier without on-chain address reuse. They make different trade-offs:

BIP 47's own text notes that versions 3 and later of payment codes are developed outside the BIP process. Neither approach is strictly better: BIP 47 puts a one-time cost and footprint on each new sender relationship, while silent payments put an ongoing scanning cost on the receiver.

Related BIPs

Silent payments are spreading into the rest of the wallet stack through several proposals:

• BIP 374: Discrete Log Equality (DLEQ) proofs, which let a signer prove an ECDH share was computed with the right private key without revealing it.
• BIP 375: sending to silent payment addresses with PSBTs, using ECDH shares and DLEQ proofs so hardware signers and multi-party transactions can create the outputs safely.
• BIP 376: spending silent payment outputs with PSBTs, by carrying the tweak each input needs.
• BIP 392: an sp() output descriptor, with spscan (watch-only) and spspend (full wallet) key encodings, for backups and wallet exports.

Backups and derivation paths

One of BIP 352's goals is to use "existing seed phrase or descriptor methods for backup and recovery". When keys come from a BIP 32 seed, BIP 352 defines hardened paths under purpose 352:

scan key:  m/352'/0'/0'/1'/0
spend key: m/352'/0'/0'/0'/0

(for mainnet, account 0). Your seed phrase is enough to recreate the keys, but finding the payments requires scanning, so a note of when the wallet was created makes recovery faster.

Things to know before using silent payments

• Wallet support varies. Both the sender's and the receiver's wallets must implement BIP 352. Check your wallet's documentation, and send a small test payment first.
• Senders use their input keys. BIP 352 recommends that all inputs in a silent payment transaction belong to the same person, because the protocol has no formal security proof for collaborative transactions such as CoinJoins.
• Signature types matter. BIP 352 calls SIGHASH_ANYONECANPAY unsafe for senders, and strongly recommends SIGHASH_ALL (or SIGHASH_DEFAULT for Taproot inputs).
• Amounts are still public. Silent payments hide the link between your address and your outputs, not the amounts or what you later do with the coins.