Silent Payments (BIP352)

Silent Payments (BIP352) is a Bitcoin wallet standard for static, reusable receiving addresses that preserve privacy. A user publishes one silent payment address — a long string beginning with sp1 — and every sender automatically derives a fresh, unique on-chain address from it. No two payments ever land on the same address, so outside observers cannot tell that multiple payments went to the same recipient, and the published address itself never appears on-chain. Unlike the older BIP47 payment code approach, Silent Payments requires no on-chain notification transaction and no prior interaction between the parties: the sender needs nothing but the recipient's static string.

Why reusable addresses are dangerous — and wanted

Bitcoin best practice says never reuse an address, because address reuse hands chain-analysis firms a ready-made cluster of your history and balance. But real life wants exactly what reuse provides: a donation string in a video description, a tip line in a Nostr profile, an invoice footer that does not change monthly. Before BIP352, the choices were bad — rotate addresses manually, run a server that serves fresh addresses, or accept the privacy leak. Silent Payments resolves the tension cryptographically: the published identifier is static, but every on-chain output is unique and unlinkable.

How the address is derived

The mechanism is elliptic-curve Diffie–Hellman (ECDH) anchored to the spending transaction itself. The recipient's silent payment address encodes two public keys — a scan key and a spend key. The sender combines the private keys of the inputs they are spending with the recipient's scan key to compute a shared secret, mixes in a hash committed to those specific inputs, and tweaks the recipient's spend key to produce a one-time Taproot output key. Because the derivation is bound to the exact inputs being spent, each payment lands on a different address with no extra on-chain data, no notification, and no interaction. The recipient — and only the recipient, holding the scan private key — can perform the mirror computation to recognize the output as theirs; the spend key (which can stay offline on a signer) is needed only to actually spend.

The scanning cost

The trade-off lands on the receiving side. Without a notification transaction telling the wallet where to look, the recipient must scan blocks, performing an ECDH computation against the input keys of candidate transactions to detect payments addressed to them. That is real work — meaningfully heavier than checking a list of known scripts — and it effectively asks for a full node or a trusted indexing server, since a light client cannot scan what it does not download. The design mitigates this: only transactions creating Taproot outputs are candidates, per-block input data can be pre-aggregated into compact "tweak" indexes, and the scan key's separation from the spend key means an always-on node can scan while keys sleep in cold storage. For a sovereign node runner the cost is mostly CPU you already own; for a phone wallet it is an architecture question wallets are still working through.

Where it fits

Silent Payments and BIP47 payment codes solve the same problem — a safely publishable, reusable identifier — with opposite trade-offs: BIP47 pays once on-chain to notify and then detects payments cheaply, while BIP352 pays nothing on-chain and detects payments by scanning. Both descend conceptually from the older stealth-address idea. For the receiver, the payments arrive as ordinary Taproot UTXOs, so downstream hygiene still matters: label them, and apply normal coin control so your unlinkable receives are not merged back together by a careless consolidation.