Silent Payments

If Bob puts an ordinary Bitcoin address on his website, anyone can track its receipts in an explorer. A block explorer is an application for looking up transactions and blocks on a particular network. Giving everyone a fresh address is better, but someone must distribute them. Silent Payments address this problem. Bob publishes fixed details, and Alice uses them to create an output for that payment: a record of an amount and the condition for spending it later. The public contact therefore does not recur as the same receiving address onchain. [1] [3] [9] [7]

A Silent Payments address includes a public scan key and a public spend key. A private key is a secret numerical value; its corresponding public key can be shared with others. The names describe their roles: the scan key relates to finding payments, and the spend key to spending them. The corresponding private keys stay with Bob. On mainnet, Bitcoin’s main network, it starts with sp1 and uses Bech32m encoding. It is neither an ordinary Taproot address starting with bc1p nor a wallet backup. This public pair lets a compatible sender calculate the payment destination, but provides neither spending authority nor a list of Bob’s receipts. [1] [5] [9]

To pay Bob, Alice’s wallet selects amounts she received earlier. References to those amounts become the inputs of the new transaction. The destination calculation uses keys from inputs that meet BIP352’s rules; not every input type qualifies. Alice combines their private keys with Bob’s public scan key using ECDH. This cryptographic method lets both sides independently obtain the same secret without exchanging private keys. The wallet uses that secret and a binding to the specific inputs to adjust Bob’s public spend key, producing the new output key. Binding the calculation to inputs prevents destination reuse when an input key is reused. If Alice uses RBF, replacing an unconfirmed transaction, for example to raise its fee, and changes the inputs, the wallet must calculate the destination again. It cannot simply reuse the previous result. [1] [4]

Bob’s wallet scans eligible transactions and calculates possible outputs using his private scan key and public input data. When it finds a match, it records the output as his funds. Onchain this is a Taproot output with no separate notification message. Bob need not be online when Alice sends or reply beforehand, but his wallet must process the necessary data later. [1] [6]

The scan key finds payments; the spend key, together with derived data, enables spending. The private spend key can be kept separate from the online scanner. A leaked private scan key alone does not let someone spend the funds, but can reveal receipts when combined with public information. Giving it to someone else’s scanning server therefore affects privacy. Neither the seed nor the private spend key should be sent to that server. [1]

Silent Payments need no special notification transaction, but computation and data transfer are not free. The recipient examines eligible transactions and performs the cryptographic calculations described above. On a phone, indexing, the source of necessary data and time since the last scan all matter. A normal list of addresses alone is insufficient. A node is software that checks transactions and blocks and communicates with other participants in the network. A personal node and an external provider have different requirements and consequences for privacy and availability. [1] [2] [8]

Bob can use labels, derived payment variants for different projects, for example. He need not perform a fully independent scan for every variant. The public variants share a scan key, however, so an observer can identify their common owner. A label helps Bob classify receipts; it does not create a separate anonymous identity. The special change label is for the remainder of Bob’s own payment. If he spends a previously received amount larger than the payment plus its fee, the remainder goes back to his wallet. This is not a merchant refund. BIP352 reserves the label m = 0 for this purpose. A wallet always scans for it during recovery and must not publish it as a contact for payments from other people. [1] [4]

Imagine Bob loses his phone but still has his backup. The seed is the secret starting value from which a wallet derives keys; users usually back it up through a Seed Phrase, recovery words in a specified order. Those words alone do not mean that any application can find Silent Payments. It must support the same key derivation and know how to discover these payments. Backing up used labels and the date the wallet first operated makes recovery easier. To recover current funds, the wallet can scan the necessary transaction data for remaining UTXOs: individually received amounts that have not yet been spent. Recovering the full history requires a broader chain scan. An empty display before scanning finishes therefore need not mean the money is lost. [1]

Silent Payments reduce links caused by address reuse, but do not hide amounts, confirmation timing or the history of spent inputs. Alice knows her own payment to Bob, and an order may carry personal information. If Bob later combines several UTXOs in one transaction, he may reveal links between them. Silent Payments are not CoinJoin, and combining them is not automatically safe: BIP352 notes the lack of a formal proof for collaborative independent senders. [1] [3]

BIP352 lists josibake, Ruben Somsen and Sebastian Falbesoner as authors; its number was assigned in 2023. When checked on 17 October 2026, its status is Complete. This does not mean every wallet supports it: sending, receiving, scanning and recovery must be checked separately. The protocol uses existing Taproot and needs no new Soft Fork, a tightening of the validity rules accepted by the network. Older applications without support cannot correctly handle an sp1 address. [1] [2]