BitcoinSecurity Intermediate

Publish One Address Forever and Stay Unlinkable

Silent Payments (BIP-352) let you publish a single static address and receive a fresh output every time. How the sender derives the address, what scanning costs the receiver, how labels work, and which wallets support it as of August 2026.

26.08.20 · 13min

Suppose someone puts a Bitcoin address on a donation page. What does that bc1q string become six months later? A donor list, a live balance disclosure, and a complete record of every amount and timestamp. Anyone can see it by pasting the string into a block explorer. Worse, it exposes the donors too. The moment a supporter's UTXO flows into that address, where they got their coins and how much they kept shows up on the same screen.

Never reuse an address is the first commandment of Bitcoin privacy. The problem is that it only applies to people who can hand a fresh address to each counterparty. A nonprofit taking donations, a merchant publishing payment details on the web, a developer with an address printed on a business card, someone paid by the same employer every month - none of them can. An address that must be published once and used many times has, until now, existed only at the cost of privacy.

Silent Payments (BIP-352) removes that dilemma. You publish one static address forever, and payments to it leave no trace on the blockchain linking back to it. What gets recorded on chain is an ordinary-looking taproot output, different every time.

Where the earlier solutions stopped

Silent Payments is not the first attempt at the static address problem.

Interactive address exchange. The receiver generates a fresh address for each payment and delivers it to the sender. Privacy is perfect, but both parties must be online at the same time, and you need a separate channel to deliver the address. A donation page cannot exchange messages with every donor. Payment servers like BTCPay Server automate this, but you have to run one, and that server learns about every payment it issues an address for.

BIP-47 reusable payment codes. A published payment code from which a new address is derived per payment. The concept matches Silent Payments, but before a sender can pay for the first time, they must broadcast an on-chain notification transaction. That transaction is the problem. It costs a fee, and more importantly it records permanently who expressed interest in that payment code. You have replaced a donor list with a list of people who intended to donate. The wallet ecosystem that championed BIP-47 has also shrunk considerably since 2024, which is part of why adoption stalled.

Silent Payments eliminates the notification transaction. The sender tells the receiver nothing, no prior contact takes place, and the payment completes in a single transaction. Hence "silent".

The sender computes the address

The core idea is an inversion. Normally the receiver creates an address and gives it to the sender. With Silent Payments, the sender derives the address themselves. They need two ingredients: the sp address the receiver published, and the private keys of the inputs they are about to spend.

What is inside an sp address

A Silent Payment address is a bech32m string starting with sp1q (tsp1 on test networks). It runs at least 117 characters, far longer than the bc1q addresses we are used to. The reason is that it carries two 33-byte compressed public keys.

Scan key (B_scan): used to find payments addressed to you. Its private key needs to be online more or less continuously.
Spend key (B_spend): required to actually spend what you find. It can stay isolated on a hardware wallet.

That separation matters in practice. Scanning only needs the scan private key, so you can keep the scan key on an always-on node while the spend key stays cold. It is the same shape as a watch-only wallet tracking a balance.

What the sender calculates

The sending wallet builds the output roughly like this.

Sum the private keys of all eligible inputs in the transaction. Call that sum a, with public key A = a·G.
Take the lexicographically smallest outpoint among the inputs and compute input_hash = hash(outpoint_L || A).
Do ECDH against the receiver's scan key: shared_secret = input_hash · a · B_scan
Derive a tweak per output: t_k = hash(shared_secret || k), with k starting at 0.
Produce the final output key: P_k = B_spend + t_k·G

P_k becomes a BIP341 taproot output directly. What lands on chain is an ordinary bc1p taproot output with no way to distinguish it from any other taproot payment. The fact that Silent Payments was used is itself invisible on chain.

The subtle part of the design is why input_hash appears in step 3. If the shared secret did not depend on the inputs, the same sender paying the same receiver twice would produce the same output key - address reuse again. An outpoint exists exactly once in the world, so a different input set guarantees a different shared secret. A fresh output per transaction is not luck; it is enforced.

The receiver runs the same math from the other side

The receiver does not know the sender's private keys. What they can see is A, the sum of the input public keys published in the transaction. By the properties of elliptic curves, input_hash · b_scan · A equals exactly what the sender computed as input_hash · a · B_scan. Both sides arrive at the same secret from different ingredients.

With the shared secret in hand, the receiver derives t_k, computes P_k, and compares it against the taproot output keys in that transaction. A match means a payment. After a match they increment k and check again, because a single transaction can send them more than one output.

What the receiver pays instead: scanning

That was the good news. The cost lands entirely on the receiving side.

Because the sender creates the output without any notification, the receiver has to find incoming payments on their own. Every new block means inspecting the transactions inside it one by one. Rather than string-matching outputs against a list of known addresses, the wallet has to run elliptic curve math per transaction.

The cost does not explode because the computation is once per transaction, not once per output. One ECDH per transaction, then the result is compared against that transaction's outputs. Still, this is not something that finishes in seconds on a laptop, and it is harder for a phone wallet to carry alone.

Fewer transactions qualify than you would think

BIP-352 specifies conditions that narrow the candidate set. A transaction is only a candidate if all of the following hold.

It has at least one taproot output
It has at least one eligible input: P2TR, P2WPKH, P2SH-P2WPKH, or P2PKH
None of its inputs spend an output of SegWit version greater than 1

The exclusions are just as explicit. Scripts with conditional branches, multisignature scripts using several public keys, and legacy inputs with uncompressed keys are all out. The rule keeps only the forms where the sender can be certain they hold the private key for the input. Taproot script-path spends are included, except when the internal key is the NUMS point, since in that case there is no spendable internal key to begin with.

Where you delegate scanning is the real fork in the road

How much privacy you actually retain is decided here.

Scan on your own full node. Your node receives every block and checks it locally. Nothing is asked of anyone else, so privacy is complete. In exchange you have to run a node and carry the indexing cost yourself.

An SP-capable indexer or server. The server precomputes tweak data and hands it to the wallet. Sparrow 2.5.0 shipped receiving this way, automatically selecting frigate.2140.dev as a required SP-capable Electrum server. The server you connect to learns at minimum that you are scanning for Silent Payments.

Filter-based light clients. BlindBit and similar designs have the server publish per-block tweaks and filters while the matching happens on the client. The server cannot tell who received what. It is the middle ground between bandwidth and privacy.

Recovery is definitively slower

Consider restoring a wallet from a seed phrase. An ordinary HD wallet derives addresses in order and queries them. A Silent Payments wallet has to rescan every block from the wallet's creation height to the present to reconstruct its balance. Writing the birth height down alongside the seed makes a concrete difference here. One extra line in the backup envelope - "2026-08-20, block 912000" - cuts recovery time dramatically.

Labels: distinguishing senders with one address

The flip side of a static address is that you do not know who paid. That is fine for a single donation page, but sometimes money arrives through channels you need to keep apart.

BIP-352's labels solve this. You add a value derived from a label integer m to the spend key, producing B_m = B_spend + hash(b_scan || m)·G, and issue an sp address carrying B_m in the spend key position. The scan key is unchanged, so scanning still happens once, and subtracting from a matched output reveals which label the money came in through. In effect you can mint an unlimited number of per-channel account numbers.

Two cautions apply.

m=0 is reserved. It is the label used to recognize your own change, so that address must never be published.

Label addresses are linkable to each other. Every label address shares the same scan key, so publishing two of them lets any observer immediately conclude they belong to the same entity. Labels are a tool for sorting incoming money, not for creating separate identities. Separating identities requires separate wallets.

Can you actually use it in August 2026?

The BIP-352 specification was merged into the BIPs repository in May 2024, and receiving implementations began landing in earnest during 2026. Here is where things stand.

Wallet	Send	Receive
Cake Wallet	Yes	Yes
Sparrow Wallet	Yes	Yes (2.5.0, May 2026)
Dana Wallet	Yes	Yes
BlindBit Desktop	Yes	Yes
BlueWallet	Yes	No
BitBox	Yes	No
Nunchuk	Yes	No
Wasabi Wallet	Yes	No
Bitcoin Core	In development	In development

Hardware signers are in better shape. BitBox02, Coldcard, Krux, and SeedSigner all sign Silent Payment transactions when paired with a software wallet. Sparrow 2.5.0 can even build a receiving wallet backed by an airgapped hardware signer.

The notable gap is that Bitcoin Core still has no released wallet support. The receiving PR remains open, while the sending PR and the SP index PR were both closed without merging. The software that sits where the reference implementation belongs is arriving last, and that is the single biggest factor in adoption pace.

In short, sending is widely supported and receiving is still a narrow field. Publish an sp address and a large share of wallet users can pay it, but to operate that address yourself you must pick from a handful of candidates.

In practice: converting a donation address

A realistic sequence for anyone adopting this now.

Choose the receiving wallet first. Sparrow is the sensible pick for desktop users with hardware wallets; Cake Wallet for mobile. If you want privacy end to end, pair it with your own node and an SP index.
Always publish a fallback address alongside it. Most exchanges still cannot withdraw to an sp address. Two lines is the practical answer: "sending straight from an exchange, use the address below; using a supporting wallet, use the sp address." The fallback will be reused regardless, so treat anything arriving there as a separately labeled set of UTXOs from the start.
Record the wallet birth height in your backup. For the recovery reason above.
Decide up front whether to use labels. Issue them if you need to separate donations, product sales, and salary. Just remember that listing several label addresses side by side on the same web page links them.

What Silent Payments does not solve

It is better to draw the boundaries clearly than to let it be oversold.

The sender still knows the output they created. Silent Payments protects the receiver from third-party observers and from other donors. It does not stop the person who paid you from watching that particular output. But all they can see is the one output they sent, not the receiver's other income. Compared with a published address that exposed everything, that is a decisive difference.

Sender-side privacy is a separate problem. Pay with a UTXO freshly withdrawn from a KYC exchange and the payment still originates from coins tied to your identity. Silent Payments fixes receiving address reuse; it does not launder input history.

It is not a substitute for CoinJoin. The two operate at different layers. CoinJoin severs the past linkage of UTXOs you already hold; Silent Payments keeps UTXOs you are about to receive from being linked in the first place. They compose, and composing them is better.

It does not do your UTXO management for you. Sweep Silent Payment outputs from different senders into one transaction as inputs and the common input ownership heuristic reveals that they all belong to one person. Merging on the spend side what arrived separated puts you back where you started.

Summary

Silent Payments fills a slot that stayed empty in Bitcoin privacy for a long time. "Publish once, receive many times" was irreconcilable with privacy, which left nonprofits and public merchants choosing between a reused address and running a payment server. BIP-352 created a third option.

The costs are honestly labeled. The receiver carries the scanning burden, recovery gets slower, and wallet choice is still narrow. As with Taproot, a protocol like this delivers its effect not on activation day but over the several years in which wallets quietly add support. Receiving support landing in Bitcoin Core is likely to be the inflection point on that curve.

Two things you can do today. If you operate a published address, try listing an sp address alongside your fallback. And when someone gives you an sp address to pay, use it. Sending support is already broad enough.