Silent payments answer a question that reusable payment codes posed in 2015: how does one published address receive every payment at a different, unlinkable output? BIP-47 answered with a notification transaction. BIP-352 answers by making the receiver read the chain. The second design deletes the announcement, the extra output and the notification’s own privacy problems, then hands the receiver a job that never ends.

The proposal states the exchange. Its motivation says the benefits “come at the cost of requiring wallets to scan the blockchain in order to detect payments”, and that the requirement “is generally feasible for full nodes but poses a challenge for light clients”. The goals list still includes “Light client/SPV wallet support”, and the appendix covering that gap is described as an area of open research. The address format is a small piece of engineering. The scanning obligation is the design.

Everything else follows from it. Taproot is the only permitted output type because a wider option set would dilute the anonymity set. A cap of 2,323 addresses per scan key exists because receiving is a computation an adversary can make expensive. Recovery asks every receiving wallet to scan for the change label, because cross-wallet compatibility depends on it. Silent payments take the privacy cost of reusable addresses out of the transaction and put it into the receiver’s software stack.

The sender computes one shared secret per transaction

An address carries a scan key and a spend key, concatenated into a 66-byte payload and encoded in bech32m with an “sp” prefix, which produces at least 116 characters. The sender adds a hash-derived tweak to the recipient’s spend key, and the tweak depends on a Diffie-Hellman result between the sender’s summed input key and the recipient’s scan key. Each payment lands on a different taproot output.

The input hash inside that tweak does quiet work. Using only a private key and the recipient’s scan key would produce the same destination every time the same coins moved, and address reuse would return through the back door. BIP-352 commits the hash to the lexicographically smallest outpoint and to the summed input public key, so the destination changes even when the same key signs again. The commitment also closes a subtler hole: without the sender’s public key inside the hash, a sender could choose a substitute private key that collides with an earlier payment and force reuse.

The tweak uses the sum of all input keys, not one chosen input. Inside a collaborative transaction that keeps the payer’s contribution private, because the recipient learns nothing about which input belonged to the payer. It also reduces the receiver’s work to one elliptic-curve multiplication per transaction instead of one per input, which the proposal says makes light-client support more feasible.

The price of that dependency is that the destination is a function of the input set. BIP-352 restricts signature hashes accordingly: ANYONECANPAY is unsafe because “the inputs must not change once the sender has signed the transaction”, SIGHASH_ALL is strongly recommended, and support for newer flags such as SIGHASH_GROUP or SIGHASH_ANYPREVOUT remains an open question. A wallet cannot build a silent payment and let another party reshape the inputs afterwards. For an ordinary payment nothing changes. For a protocol that expects to renegotiate a transaction before broadcast, an option disappears.

Coin selection is constrained as well. The sender needs at least one input from the permitted set, has to exclude prevouts with a SegWit version above 1, and for every taproot input must hold the private key for the output key unless that output uses a nothing-up-my-sleeve internal key. A wallet holding only exotic script types cannot construct the payment at all, which is one more way the scheme depends on software support at both ends.

Receiving is a mandatory job with a published ceiling

The scanning rule is not optional. For version 0, a transaction must be scanned when it is consensus-valid, contains at least one taproot output, has at least one input from a permitted script type, and does not spend an output with a SegWit version above 1. The permitted inputs are P2TR, P2WPKH, P2SH-P2WPKH and P2PKH. A wallet that skips a matching transaction can miss a payment permanently, because nothing on chain marks the output as belonging to it.

For each qualifying transaction the receiver recomputes the input hash, performs the Diffie-Hellman step with the scan private key, then tests candidate outputs against every taproot output in the transaction while incrementing an index. A payment is found by trial, not by lookup. That is the work the sender never sees, and it runs whether or not the wallet has ever been paid.

The specification puts a number on how bad the trial can become. One transaction may hold up to 23,255 outputs; if all of them target one recipient, the naive scan grows quadratically and the proposal estimates “several minutes on modern systems”. K_max, a limit of 2,323 addresses per scan key inside one transaction, cuts the worst case and, in the document’s words, “cuts down the scanning cost to the order of tens of seconds”.

The parameter is evidence that the authors treated scanning as an attack surface rather than an implementation detail. It doubles as an operational limit. A payout that batched more than 2,323 recipients sharing one scan key into a single transaction would fall outside the specification, and the sender is required to fail rather than produce a transaction the receiver cannot fully scan. Privacy designs rarely publish a number that constrains their users’ batch sizes. This one does, and the number is the honest part of the document.

A split key pair, and labels that cluster

The two-key structure keeps the key that must be online away from the key that can spend. A wallet can leave the spend key in cold storage and run the scan key on a server, which is the workable arrangement when scanning is continuous. The split is what makes continuous scanning tolerable: the device that watches for payments never holds the key that can move them.

Labels handle reconciliation. A recipient who wants to know which customer paid publishes labeled spend keys derived from the same scan key, and the wallet identifies a label by subtracting the derived output from each candidate output. Label zero is reserved for change, which the proposal frames as “an alternative to using BIP32 for managing change” that still lets a wallet know which outputs were its own when recovering from the master key.

The limit sits in the same section. Because every labeled address shares the scan key, “an outside observer can easily deduce” that the labels belong to one entity. The document concludes that labels “are not meant as a way for Bob to manage separate identities, but rather a way for Bob to determine the source of an incoming payment”. A merchant can separate customers internally. It cannot present two unlinkable storefronts by publishing two labels.

Publishing separate addresses instead multiplies the scanning work, which the proposal calls “prohibitively expensive”. That sentence carries the economics of the scheme: each additional privacy compartment costs the receiver another pass over the chain.

Taproot only, because the output should not stand out

BIP-352 permits only taproot outputs. The reason given is that too much optionality “makes it difficult to implement and can be at odds with the goal of providing the best privacy”, with taproot described as putting users in “the best eventual anonymity set”. BIP-341 had made the matching argument at the output level. It “seeks to minimize how much information about the spendability conditions of a transaction output is revealed on chain at creation or spending time”, and its two construction rules point the same way: commit to an unspendable script path when no script path is needed, and pick a fresh random value when a nothing-up-my-sleeve internal key is used, so the output does not reveal that key-path spending is impossible.

Silent payments inherit that property. A silent payment output is an ordinary taproot key with no marker, no notification and no registry. It disappears into the taproot population, which is what the goals promise when they say transactions “blend in with other bitcoin transactions and can’t be distinguished” and cannot be linked to a silent payment address “by an outside observer”.

The cost of that success is measurement. An output designed to be indistinguishable cannot be counted from chain data, so any estimate of how many silent payments exist describes wallet software rather than the blockchain. Researchers can count taproot outputs. They cannot count silent ones, and a feature that cannot be counted cannot be judged by adoption metrics.

What BIP-47 had to add, and what silent payments removed

In BIP-47 a payment code is “an extended public key and associated metadata”, and its notification address is the P2PKH address of the zeroth derived key. Before the first payment, “Alice MUST inform Bob of her payment code via the following procedure”, and the code travels in an 80-byte OP_RETURN output attached to a small payment.

That choice creates four obligations. Notification outputs must not be shown as spendable balance. They must not be used as inputs in transactions that perform the payment-code arithmetic. Change from a notification transaction can reveal the connection between the parties, so wallets “SHOULD mix change outputs from notification transactions prior to spending them”. And every new relationship opens with an extra transaction whose only job is to establish state, a cost paid in fees and block space.

Silent payments delete all four. No announcement, no OP_RETURN, no quarantined coin, no change-mixing rule, because there is no on-chain message. The bill moves to the receiver, who scans whether or not anyone pays. The shape of the cost improves, since a per-relationship expense becomes a per-wallet one and a wallet that receives nothing pays almost nothing in fees, though it still scans.

Both documents carry a status field. BIP-47 reads “Deployed”. BIP-352 reads “Complete”. Neither describes wallet support, and the difference is a useful warning. A specification can be finished, and even marked deployed, while remaining optional for every wallet that would have to implement it. Sender support and receiver support are separate adoption problems, and the cryptography solves neither.

The limits the proposal does not remove

Amounts and timing stay public. The recipient’s output, its value and the sender’s inputs are all visible, so an analyst who already suspects a relationship can test it against values and times. Because the tweak commits to the summed input keys, the destination is derived from the whole eligible input set, so a sender cannot produce a different destination by selecting one input instead. All of those inputs stay visible on chain.

CoinJoin compatibility is narrower than the goals suggest. The goals list compatibility with “other spending protocols, such as CoinJoin”, while the motivation recommends that the keys of all inputs belong to one entity because there is no formal proof that the protocol is secure in a collaborative setting. The specification also excludes inputs with conditional branches or multiple public keys from the shared secret, since a malicious participant could derive a destination with one set of keys and re-sign with another. Collaborative payments are contemplated. The security argument for them is incomplete by the authors’ own account.

Light clients remain the open problem. A wallet without a full node needs transaction-level data to test candidates, and the proposal concedes that even a privacy-preserving light client would pay in bandwidth. Its own sketch of that path needs the summed public key per eligible transaction plus block filters, and it asks how a receiver can source that material “in a trustless manner” without answering. Any deployed light wallet therefore makes a trust choice the specification does not make for it, which turns the privacy of the scheme into a property of the wallet vendor.

How to read the trade

The design does what its goals claim. Transaction size does not grow, outputs blend in, no interaction is required, payments from one sender cannot be linked to each other, and each payment lands on a unique address. Those are properties of the construction rather than assertions about the world, and they hold without a trusted third party. A proposal that publishes its own denial-of-service parameter and names its unsolved light-client problem is also candid about where the edges are.

For a wallet builder the consequences are concrete. The scan key must be online, so the device holding it needs a threat model separate from the spending device. The receiver has to keep checking further indices after a match, which the overview makes explicit, and the recovery guidance asks every receiving wallet to scan for the change label for cross-wallet compatibility, even when no labels were used.

For a payout operator the constraint is arithmetic. A batch that pays more than 2,323 addresses sharing one scan key in a single transaction cannot be represented within the specification, so large disbursements have to be split across transactions or across scan keys. That is a design limit rather than a defect, and it matters more to an exchange than to an individual.

What would change this reading is evidence from the software layer. A light-client scheme that sources the key material without a single trusted indexer would remove the main architectural objection. Wallets that scan locally rather than delegating every query to one provider would make the privacy claim meaningful for the users who need it most. Until then, silent payments are a privacy upgrade with a bill attached, and the receiving side pays it.

Sources