The Problem With Giving Out One Address

You post your Bitcoin address on a freelance invoicing page. Payments arrive. Everything works, right up until someone pastes that string into a block explorer and reads your entire history like a bank statement left open on a coffee shop table: amounts, timestamps, how many distinct senders, all of it. Your static address is a glass mailbox.

Silent payments solve this without requiring a server, a handshake, or any message exchanged between you and the person paying you. The sender derives a brand-new address on their end, entirely from information already on-chain, and you find your payment by scanning the chain yourself. No coordination. The address is unique every time, and the funds still arrive.

That's the answer in one paragraph. Now let's open the hood.

The Cryptographic Trick That Makes It Work

Silent payments, formalized in BIP-352, are built on a property of elliptic-curve cryptography called Diffie-Hellman key exchange. Two parties each contribute half of a shared secret, and the result is a value only they can compute, without either one ever transmitting that secret across the wire.

Here is the mechanism, stripped to its essentials.

You, the recipient, publish a silent payment address. It encodes two public keys: a spend key and a scan key. The scan key is the antenna you use to find incoming payments; the spend key is the lock on the mailbox itself.

When Alice wants to pay you, her wallet does the following:

  1. It takes the private keys of the UTXOs she is spending in this transaction.
  2. It combines those private keys via a sum into a single scalar value.
  3. It multiplies that scalar by your published scan public key. Elliptic-curve multiplication is one-way: knowing the result and your public key, no outside observer can reverse-engineer Alice's private keys.
  4. The result is a shared secret specific to this exact transaction.
  5. Her wallet hashes that shared secret (with a small integer counter, starting at zero) and adds the result to your spend public key, producing a brand-new public key that has never appeared on-chain before.
  6. She pays to the P2TR (Taproot) address corresponding to that derived key.

Now you need to find it. Your wallet takes your scan private key, multiplies it by the sum of the input public keys from any candidate transaction, and arrives at the same shared secret Alice computed. It derives the same expected address. If it matches an output in the block, you have found your payment.

Nobody watching the chain can link that output to your silent payment address, because the derivation used Alice's specific UTXOs as input. Two senders produce two completely unrelated addresses even when both are paying the same recipient. The counter in step five matters when Alice sends multiple outputs in one transaction: the first uses counter zero, the second uses counter one, and your scanner increments through them until it finds no match.

A Concrete Scenario: Two Friends, One Invoice

Say Marcus and Priya both owe you 0.05 BTC for the same piece of work. You send them both your silent payment address (Bech32m format, beginning with bc1p, longer in practice than any example printed here).

Marcus sends from a wallet holding one UTXO. His wallet computes the shared secret, derives output address A, and broadcasts the transaction. Address A has never appeared on-chain before.

Priya sends separately from two UTXOs she consolidates. Her wallet sums her two input private keys, multiplies by your scan key, and derives output address B. Completely different from A, because her inputs were different.

You run a scan over both blocks. Your wallet independently re-derives A and B, recognizes both as yours, and credits your balance. An outside observer sees two unrelated Taproot outputs paying two unrelated addresses. Nothing to cluster, because the inputs that generated each secret were never the same.

That is not a theoretical property. It is arithmetic. The outputs are unlinkable by construction, not by policy.

The Scanning Cost, and Why It Matters

This is where silent payments ask something of you. Traditional wallets scan for addresses you have pre-generated and registered with a server. Silent payments require inspecting every transaction in every block that carries Taproot inputs, because you cannot know in advance which transactions were meant for you.

For a full node, manageable. For a light client on a phone, expensive.

BIP-352 acknowledges this directly and points toward a future in which trusted index servers, or compact block filters adapted for silent payments, reduce the computational burden. As the protocol currently stands, light-wallet support requires a tradeoff: either trust a server that scans on your behalf, or accept slower sync times. A recipient who has been offline for two months and holds a busy address will need to work through a substantial number of blocks.

Most enthusiasts skip past this limitation, and that is a disservice to anyone evaluating the protocol seriously.

The other side of the ledger: that scanning work is entirely local and private. You are not querying anyone about which outputs belong to you. The privacy model stays intact precisely because the cost falls on you.

What People Assume That Isn't Quite Right

The most common misconception is that silent payments are essentially the same as stealth addresses from Monero or earlier Bitcoin proposals. They share a family resemblance, but BIP-352 was designed specifically to avoid requiring an ephemeral data field inside the transaction itself.

Earlier Bitcoin stealth address schemes, including Peter Todd's 2014 proposal, required an OP_RETURN output to carry the sender's ephemeral public key. That added on-chain overhead and was, in itself, a fingerprint pointing to the use of a privacy mechanism. Silent payments use the transaction's existing inputs as the entropy source. No extra output, no special marker. A silent payment transaction is indistinguishable from an ordinary Taproot transaction to anyone who does not know to look for it.

One more thing worth stating plainly: silent payments do not hide amounts. Output values remain visible on-chain, exactly as with any other Bitcoin transaction. The privacy gain is address unlinkability, not confidential transactions. Confidential transactions are a separate problem requiring separate cryptography, specifically something like Pedersen commitments, which Bitcoin does not currently support at the base layer.

Has your wallet software supported BIP-352 long enough that you have already generated a silent payment address? If so, you are ahead of most users. The tooling is still maturing, which is an accurate description of where the ecosystem sits, not a criticism.

The deeper point is this: silent payments represent a design philosophy in which privacy is a property of the protocol, not a feature you access by routing funds through a mixer or switching to a separate privacy coin. The address you hand someone cannot be used to surveil you across multiple payments, because the address they actually pay is never the address you published. That is not obfuscation dressed up in technical language. It is just math, working quietly, and getting the accounting right.