Bitcoin Silent Payments: A Hands-On Guide (2026)

A note on funding: CypherpunkGuide carries no surveillance advertising — no ad networks, tracking pixels, or sponsored content. It is funded by transparent streams: reader donations now; subscription and editorially-aligned affiliate later. We answer to our readers, not to advertisers.

There is a small, quiet contradiction at the center of receiving Bitcoin. Every guide tells you never to reuse an address — reuse is one of the cleanest signals a chain-analyst has. Yet the moment you want to be paid — a tip jar in a bio, a donation line in a README, an invoice you send once and forget — you need an address that stays put. Rotating addresses and static identity pull in opposite directions.

Silent Payments (BIP-352) are the protocol that resolves it: you publish one address, and every person who pays you derives a different on-chain address for it, so an observer watching the chain sees unrelated outputs with no shared destination. It is among the most significant changes to receiving privacy in years. It is also widely misunderstood, half-shipped across wallets, and carries a real cost that the enthusiastic write-ups tend to gloss.

I write under a pseudonym and treat every coin I hold as already watched, so I did not want to take the protocol on faith. Before writing a word of this guide, I wrote a from-scratch implementation of BIP-352 in Python — using libsecp256k1 through the coincurve library — and ran it against the specification’s official test vectors: 28 of 28 sending sub-cases and 29 of 29 receiving sub-cases matched, bit for bit, in under 200 milliseconds (bundle log). What follows is the working version — what it protects, which wallets deliver it in 2026, and the scanning cost you should understand before you rely on it.

What a Silent Payment Actually Is (and What It Doesn’t Protect)

#

A Silent Payment is a reusable Bitcoin address, defined by BIP-352, that lets a payer derive a unique, unlinkable on-chain address for you from a single string you publish once. It protects the receiving link — the connection between separate payments to the same identity — and nothing else. It does not hide amounts, it does not protect your senders, and it does nothing about the off-chain records that tie coins to your name.

The address is two public keys — a scan key and a spend key — encoded together. On mainnet it begins with sp1; on a test network it begins with tsp1 (the human-readable prefix is sp / tsp, and the 1 is just the bech32m separator). When someone pays you, their wallet combines its own input keys with your scan key to compute a shared secret, and from that secret derives a fresh Taproot output that only you can detect and spend. No two payers produce the same output, and there is no “notification transaction” announcing the link, the key improvement over the older BIP-47 payment-code approach.

What it leaves exposed is worth stating plainly, because the word “private” does a lot of unearned work in this space. Silent Payments are a receiving tool. The amount you receive is still visible on-chain. The payer’s own privacy is their problem, not yours. And the strongest attack on a named pseudonym is rarely the chain at all — it is the writing, the metadata, the KYC exchange where coins meet a passport. That is the additive model laid out in how on-chain tracing actually works and, off-chain, in AI deanonymization. Silent Payments close one specific, valuable gap. They are necessary, not sufficient.

Which Wallets Support Silent Payments in 2026

#

Support is real but uneven, and the single most useful habit is to check sending and receiving separately — they shipped at different times, in different wallets, sometimes years apart. Sending to a Silent Payment address is now common; being able to receive to one, which requires the wallet to scan the chain, is newer and rarer. The table below reflects primary sources as of 2026-07-09; verify against each project’s release notes before you move real money, because this list moves.

Two cautions the table compresses. First, “receive” is the line that matters and the one that lags — a wallet can let you pay a friend’s sp1 address long before it can hold one of your own. Second, the way a wallet scans is a privacy decision, not just a performance one, and it is the subject of the next two sections. For acquiring the coins you will receive this way in the first place, without seeding the identity link at the exchange, see buying Bitcoin without KYC.

Sending: The Easy Half

#

Sending to a Silent Payment address is the straightforward half of the protocol, because the sender does all their work locally and never has to scan anything. In a wallet that supports it — Sparrow is the reference desktop experience — you paste the recipient’s sp1… address into the send field exactly as you would any other, and the wallet does the derivation invisibly.

Under the hood, your wallet takes the private keys of the inputs it is spending, combines them with the recipient’s scan key to compute a shared secret, and uses that secret to derive a one-time Taproot output address for this specific payment. Because the derivation folds in your inputs, the same recipient address yields a different on-chain output every time a different person — or a different set of your coins — pays it. The sender needs nothing from the recipient beyond the published address: no round-trip, no notification, no interaction. That is why send-side support arrived first and is now the common case. The asymmetry is the whole story of the next section: the cost that sending avoids is precisely the cost that receiving cannot.

Receiving: The Scanning Cost Nobody Warns You About

#

To receive Silent Payments, your wallet must examine candidate outputs across the blockchain and test each one against your keys to find the payments meant for you — there is no address on the chain to simply “look up.” This scanning cost is the central, under-reported tradeoff of BIP-352, and how your wallet resolves it determines both your convenience and your privacy. Publishing the address is free. Finding what was sent to it is not.

If you run your own full node, scanning is a local computation over block data — demanding but private, because nothing leaves your machine. The friction appears when you want to receive on a phone or a laptop without a node. That is where an indexing server comes in. For Sparrow, the server is Frigate (a Silent Payments Electrum server, latest v1.5.3), and a public instance exists at frigate.2140.dev. You do not “visit” it in a browser — it speaks the Electrum protocol, not HTTP. In Sparrow you choose it under Preferences → Server → Public Server, then test the connection.

Here is the part the cheerful tutorials skip, and it is a privacy point, not a footnote. To let a server scan on your behalf, your wallet hands that server your scan private key and your spend public key. Even when the server holds them only in memory, as Frigate is designed to, a malicious or compromised indexer can use them to reconstruct exactly the picture Silent Payments are meant to deny an observer: the full list of payments you have received. The hands-on guide at bennet.org says it directly — a bad server “could build exactly the picture of your receiving history that Silent Payments are meant to prevent.” So the honest framing is a spectrum: your own node is fully private and more work; a public indexer is convenient and asks you to trust its operator with your receiving history. Choose deliberately, and do not let “I use Silent Payments” become a false sense of safety when a stranger’s server is doing your scanning.

I Reproduced BIP-352 by Hand

#

The fastest way to trust a privacy protocol is to make it run and check it against the specification’s own numbers, which is what I did rather than take the claims on faith. My from-scratch implementation reproduces all 57 official test-vector sub-cases exactly — 28/28 sending, 29/29 receiving — and the full log plus the scripts ship with this article (bip352-verification.txt), so you can reproduce them yourself. More useful than the pass count, though, is watching a single payment derive step by step.

Take one published address and trace what a sender computes. The values below are real, from the specification’s own test vectors:

Now the property that makes the whole thing worthwhile. I constructed a second, independent sender myself — different key material, a notional different coin — paying the same published address (no transaction is broadcast here; like the trace above, this is pure derivation). Its output was 3f1dd702…879b98ad. Two payments, one address, and on-chain the two outputs share nothing: no common address, no visible link. Only the holder of the scan key can run the reverse computation and recognize both as theirs. That is the receiving-privacy guarantee, and you can watch it hold in the trace rather than believe it as an assertion. It is the on-chain counterpart to the reuse problem dissected in Bitcoin on-chain privacy — the same clustering that reuse hands an analyst for free is exactly what this derivation withholds.

The Gotchas: Multisig, Labels, and the K_max Limit

#

Beyond the scanning cost, three implementation details decide whether Silent Payments fit your setup — and each is the kind of thing you want to learn before you rely on it, not after. These are the corners the how-it-works explainers rarely turn.

• Multisig and collaborative transactions are awkward. Because a sender derives the payment from the private keys of the inputs being spent, sending from a multisignature wallet or a CoinJoin — where the signing keys are split across parties who must not simply pool them — does not compose cleanly with BIP-352. Silent Payments solve the reuse link, not the mixing problem; if you want amount and graph privacy, that is still the province of collaborative transactions, covered in on-chain privacy. Treat them as complementary, not interchangeable.
• Labels are convenience with an asymmetry. BIP-352 lets a receiver derive labeled variants of one address — useful for telling apart which outputs came from which source. The label information is meaningful only to you, the holder; it is not exposed on-chain. But it is bookkeeping you keep, which means it is bookkeeping a compromised wallet or backup can leak. Convenience, tracked honestly.
• There is a recipient limit, K_max = 2323. The specification (v1.1.0, March 2026; current v1.1.1, April 2026) caps how many outputs a single group may derive, as a defense against transactions crafted to blow up a receiver’s scanning work. You will never hit it as an individual — but it is why a naïve “pay 3,000 outputs to one address” fails by design, and it tells you the protocol authors took the scanning-cost attack seriously.

A related reality check on light clients, since it is where people expect the scanning problem to be already solved: as of mid-2026 there is no single production-ready, trust-minimized light-client tool you can just install. The blindbitd wallet daemon was archived in August 2025; only its companion indexer, blindbit-oracle, is actively maintained, and the light-client specification is still a work in progress. Experimental libraries like bdk-sp exist, but their own authors warn against mainnet use. If a guide implies phone-based Silent Payments receiving is a solved, no-tradeoff experience, it is ahead of the software.

Bottom Line: Should You Use Silent Payments Yet?

#

Silent Payments are ready for a specific, valuable job — a reusable public receiving address that does not leak a reuse link — and not yet ready to be your only privacy tool or a frictionless mobile default. Match the tool to the job, and run your own node if the receiving history is sensitive. The honest goal here is better receiving privacy, not anonymity.

Whatever your case, the sequence is the same as it always is: name the adversary, fix the cheap and irreversible links first — no-KYC acquisition where lawful, coin hygiene, never reusing a plain address — and add Silent Payments where they close the specific gap of a published address you want kept unlinkable. It is a genuine advance. It is also a receiving tool with a scanning bill, and knowing who pays that bill — you, or a server you trust — is the difference between privacy and the feeling of it.

Frequently Asked Questions

#

What is a silent payment address?

#

A silent payment address is a reusable Bitcoin address, defined by BIP-352, that you can publish once — it begins with sp1 on mainnet. Unlike an ordinary address, every payer derives a different one-time on-chain address from it, so payments to you carry no shared, linkable destination. It encodes two public keys (a scan key and a spend key) rather than a single script.

Do Silent Payments hide the amount I receive?

#

No. Silent Payments protect the receiving link — the connection between separate payments to the same identity — and nothing else. The amount of each payment is still recorded on the public blockchain, your senders’ own privacy is unaffected, and off-chain records (such as a KYC exchange) are untouched. For amount privacy, Lightning or collaborative transactions are the relevant tools.

Which wallets support Silent Payments in 2026?

#

As of 2026-07-09, Sparrow supports both sending (since v2.3.0, October 2025) and receiving (since v2.5.0, May 2026); Cake Wallet supports both with on-device scanning (since v4.18.0, late May 2024). Bitcoin Core’s wallet-level support is not yet merged, though the underlying cryptographic module is. Always check send and receive support separately, and verify against current release notes.

Why is receiving a Silent Payment slow?

#

Because there is no address on the chain to look up. To find payments sent to you, your wallet must scan candidate outputs across blocks and test each against your keys. On your own node this is a private local computation; without a node, you rely on an indexing server, which is faster but introduces a trust tradeoff. Light-client tooling that removes both the cost and the trust is still a work in progress.

Are Silent Payments still private if I use a public server?

#

Only partially. To scan on your behalf, a public indexer receives your scan private key and spend public key. Even held only in memory, those keys let a malicious or compromised server reconstruct the full history of payments you have received — the very thing Silent Payments are meant to prevent from a chain observer. Running your own node avoids this; a public server trades that privacy for convenience.

Three threads on this site connect here. Silent Payments answer the receiving half of the reuse problem dissected in Bitcoin On-Chain Privacy: How Tracing Works — read that for what clustering sees and what it doesn’t. Because the address is only as private as the coins you receive into it, pair this with Buying Bitcoin Without KYC, which fixes the identity anchor upstream. And because the chain is never the whole threat, AI Deanonymization covers the off-chain inference that runs in parallel to all of it.