Silent Payment Scan Key

Silent payment scan key is the detection half of the two-key design that makes BIP352 silent payments practical. A silent payment address encodes two public keys: a scan key (Bscan) and a spend key (Bspend). The corresponding private scan key (bscan) lets a wallet find incoming payments on-chain, while the private spend key (bspend) is what actually authorizes spending them. Splitting detection from spending is the design decision that lets a silent-payments wallet keep its spending capability in cold storage while an always-online device handles the continuous work of watching the chain.

What the scan key does

Silent payments deliberately have no handshake — no notification transaction, no on-chain signal of any kind. Instead, the sender derives a unique output for the recipient using ECDH between the sender's input keys and the recipient's published scan key, tweaked so that every payment lands on a fresh, unlinkable address. The recipient's side of that computation runs in reverse: for each candidate transaction, the wallet combines its private scan key with the sum of the transaction's eligible input public keys (plus an input hash) to regenerate the shared secret, derives the candidate output as the spend key plus a tweak, and checks whether that output actually appears in the transaction. A match means an incoming payment. This is why scanning is mandatory work in BIP352: the chain contains no marker, so the recipient must test transactions to discover their own money — the price paid for leaving zero setup footprint.

Why the split matters

Scanning is continuous and must run on a connected machine — a home server, a node companion, a phone — which is exactly the environment where key exposure is most dangerous. The two-key design contains that risk precisely: the online scanner holds only bscan, so a full compromise of that device reveals which payments you received — a real privacy loss — but cannot move a single satoshi, because signing requires the spend key that never left the offline device or hardware wallet. This mirrors the watch-only-wallet discipline sovereign Bitcoiners already practice, but enforced at the protocol layer rather than by wallet convention: detection capability and spending capability are cryptographically different keys, not just different files.

Practical realities

The scanning burden is the honest cost of the scheme. Testing every transaction requires access to input public keys, which favors wallets backed by a full node or a purpose-built index; lightweight clients need help, and outsourcing scanning to a third party by handing over your scan key surrenders exactly the privacy the protocol was built to protect — the scan key holder sees every payment you receive, forever. Running your own infrastructure is not a nice-to-have here; it is the difference between having the privacy and simulating it. Silent payments were designed with Taproot outputs in mind, and the address format is generated once and published anywhere — a donation page, a profile, a signature line — without ever creating on-chain address reuse. Label support extends this further, letting a single scan key serve multiple receiving identities — donations versus invoices, say — each still detected by the same scanning pass.

Where it fits

The unlinkability the scheme delivers is detailed under output linking resistance, and the static-address pattern it perfects is covered under reusable payment address. The scan key is the piece that makes the whole arrangement livable: publish one address for life, let a machine you own do the watching, and keep the keys that move money where they belong — offline, in your custody, doing nothing until you decide otherwise.