Silent Payments
Silent Payments (BIP 352) is a protocol for static Bitcoin payment addresses. A receiver publishes one address. Each payment is sent to a unique Taproot output that an outside observer cannot link to that address. The protocol does not require interaction between sender and receiver, and it does not create an on-chain notification output.
A Silent Payments address is a Bech32m string. On mainnet it begins with sp1q. On test networks it begins with tsp1q. A typical mainnet address is 117 characters and encodes two public keys: a scan key and a spend key. The scan private key may be kept on an online device. The spend private key may be kept offline. The outputs created by the protocol are ordinary BIP341 taproot outputs. The resulting transactions are not distinguishable on-chain as Silent Payments.
Background
Using a new address for every payment avoids address reuse, which is an important privacy practice. Distributing a fresh address for each payment requires interaction. Publishing an xpub or reusing a single output script lets observers cluster incoming payments.
Earlier static-address designs used an on-chain notification so the receiver could find the payment. Notifications add cost, make the payment easier to fingerprint, and can allow the receiver to link multiple payments from the same sender.
Silent Payments derive a one-time taproot output from the sender's inputs and the receiver's published keys, so no notification output is required. The receiver (or a server the receiver trusts) must scan eligible transactions to detect payments. Scanning is practical for a full node. Light-client scanning is more expensive and is described as an area of research in BIP 352.
How it works
The receiver publishes a pair of public keys (Bscan, Bspend). The sender sums the private keys of the inputs used for shared-secret derivation, performs ECDH with Bscan, and includes a hash of the lexicographically smallest outpoint so that reusing the same input script does not produce the same destination. The resulting tweak is added to Bspend and encoded as a taproot output. Additional outputs to the same receiver increment a counter k.
The receiver recomputes the tweak using the scan private key and the summed input public keys, then checks whether the derived taproot key appears among the transaction outputs. After the first match, the receiver continues incrementing k until a derived key is not present.
Inputs that contribute to the shared secret are P2TR, P2WPKH, P2SH-P2WPKH, and compressed P2PKH. Inputs with several public keys, such as multisig, are excluded because a collaborator could change keys after the Silent Payment output was derived. Transactions that spend SegWit version > 1 are not scanned, so a later version of the protocol can introduce new rules without scanning the same transaction twice.
BIP 352 states that collaborative transactions (including some CoinJoin and MuSig/FROST constructions) are possible but not recommended, because there is no formal security proof unless all input keys belong to the same entity.
Optional labels tweak the spend key so the receiver can distinguish sources of payment. Label m = 0 is reserved for change. Multiple labeled addresses that share a scan key are visibly related, so labels are not a method of maintaining separate identities.
Implementations
Sending to a Silent Payments address and receiving to one are separate features. Receiving requires a scanner.
As of August 2026:
- Bitcoin Core does not include Silent Payments in a released wallet. A silentpayments module is present in libsecp256k1. Wallet work is tracked in bitcoin/bitcoin#28536.
- Cake Wallet can send and receive (v4.18.0, May 2024). Scanning is performed on the device.
- Sparrow can send (v2.3.0, October 2025) and receive (v2.5.0, May 2026). Receiving typically uses a Silent Payments-capable Electrum server such as Frigate.
- Electrum does not have in-tree support. Pull request #9900 was declined in favor of an external plugin. A send-only plugin exists.
Hardware signing support depends on the device. Related PSBT fields are specified in BIP 375.