• Silent Payments — Bitcoin’s Privacy Layer
  • The Problem Silent Payments Solve
  • How It Works
    • The Scan/Spend Key Split
  • The Scanning Cost — The Real Tradeoff
    • The K_max Attack and Fix (February 2026)
  • The Ecosystem Right Now (March 2026)
    • Wallet Support
    • Infrastructure Milestones in Q1 2026
  • Silent Payments vs BIP-47 PayNyms
  • Open Questions
    • CoinJoin Integration
    • Light Client Architecture
    • Nostr Integration
  • My Take
  • Related Notes
  • Sources

§Silent Payments — Bitcoin’s Privacy Layer

#bitcoin #privacy #BIP352 #taproot #wallets

[!info] BIP-352 Silent Payments let you publish a single static address that generates a unique on-chain output for every payment received — no interaction, no server infrastructure, no address reuse. Proposed by Ruben Somsen in March 2022, merged as BIP-352 in May 2024.

§The Problem Silent Payments Solve

Bitcoin has always had a privacy tension: best practice says never reuse addresses, but the alternatives all have costs.

• Static address → everyone sends to the same place. Chain analysis trivially clusters all incoming payments.
• Server-generated addresses → requires always-online infrastructure, introduces a trusted third party.
• XPUB sharing → reveals your entire transaction history to anyone who has it.
• BIP47 PayNyms → requires a notification transaction that’s publicly visible, linking sender to recipient before any payment even happens.

Silent Payments eliminate all of these tradeoffs. One static sp1... address enables unlimited unique on-chain payments. Each payment looks like any other Taproot output. No observer can link two payments to the same recipient without the recipient’s scan key.

§How It Works

The cryptography is elegant:

1. Sender takes the private keys from their transaction inputs and the recipient’s public scan key.
2. ECDH produces a shared secret known only to sender and recipient.
3. Shared secret + recipient’s spend key → unique one-time Taproot output address.
4. Recipient scans each transaction: takes the aggregated input public keys, performs ECDH with their private scan key, derives what the output should be, checks for a match.

The key design choice: using transaction input keys (already present in every transaction) instead of requiring any additional on-chain data. Zero extra footprint. The payment is indistinguishable from a normal P2TR output.

§The Scan/Spend Key Split

Silent Payment addresses encode two public keys:

• Scan key — used to detect incoming payments (can be delegated to a server for convenience, at the cost of revealing payment history to that server)
• Spend key — required to actually move the funds

This split is critical. You can hand a scan key to a watch-only service without giving it the ability to spend. It’s a natural separation of concerns that existing Bitcoin addresses don’t have.

§The Scanning Cost — The Real Tradeoff

This is the elephant in the room. Unlike traditional wallets that check a pre-generated list of addresses against the UTXO set, Silent Payment recipients must:

1. Look at every transaction with eligible inputs
2. Perform an ECDH computation per transaction
3. Compare the derived output against actual outputs

For a full node, this means processing every block’s transactions cryptographically. Optimizations help:

• Skip non-Taproot outputs (SP only produces P2TR)
• Skip dust outputs
• Use tweak indices (33 bytes per potential output) instead of full transaction data
• Transaction cut-through and specialized indexes

But it’s still fundamentally more expensive than traditional scanning. This is the price of privacy without interaction. Light clients need a new type of server that serves “tweak data” — which is where the recent infrastructure work comes in.

§The K_max Attack and Fix (February 2026)

Sebastian Falbesoner discovered a theoretical attack: an adversary constructs a transaction with the maximum allowed taproot outputs (23,255 per block under consensus rules), all targeting the same entity. Without limits, scanning this takes minutes instead of tens of seconds.

The fix: a new parameter K_max limiting per-group recipients within a single transaction. The proposed value was 1,000, but BIP-352 was updated to set it at 2,323. Practical impact is minimal — no legitimate use case needs thousands of outputs to the same silent payment group in one transaction. But this shows the protocol is still maturing, and edge cases in the scanning model need careful attention.

§The Ecosystem Right Now (March 2026)

§Wallet Support

The adoption picture from silentpayments.xyz:

The ecosystem is growing fast. Six months ago it was basically Cake and Silentium. Now there’s a genuine wallet ecosystem forming.

§Infrastructure Milestones in Q1 2026

Three big developments:

1. BIP-392: Silent Payment Descriptors (published March 2026) — Defines the sp() descriptor format. This is the plumbing that lets wallet software know how to scan for and spend SP outputs. Supports single-key (spscan/spspend encoded keys) and two-key forms (separate scan + spend keys, including MuSig2 aggregate keys via BIP-390). This is what makes SP wallets interoperable at the descriptor level.

2. BIP-375: PSBT Integration (merged January 2025) — Specifies how to send silent payments using PSBTs. Each signer computes an ECDH share and DLEQ proof for inputs they control. This is critical for hardware wallet workflows and multi-signer setups.

3. Electrum Server for Testing (January 2026) — A test Electrum-protocol server serving SP tweak data. This is the light client infrastructure that will make mobile SP wallets practical without running a full node.

4. Descriptor Annotations (February 2026) — Craig Raw (Sparrow dev) proposed adding metadata like wallet birthday (block height) to descriptors. For SP wallets, this means scanning can start from a known point instead of the full chain, dramatically improving recovery time.

§Silent Payments vs BIP-47 PayNyms

Silent Payments are strictly better on privacy. BIP-47 is currently easier for light clients. But the infrastructure gap is closing fast.

§Open Questions

§CoinJoin Integration

Using SP in a collaborative setting (like CoinJoin) is explicitly left as future work in BIP-352. The challenge: in a CoinJoin, multiple signers contribute inputs, and a malicious participant could re-broadcast with different keys, breaking the address derivation. A blinding scheme exists (using DLEQ proofs to hide the SP address from other participants), but it’s not formally proven secure. Wasabi’s addition of SP support makes this research urgent.

§Light Client Architecture

The current model requires downloading 33 bytes per potential output and performing ECDH to check ownership. Privacy-preserving scanning means the server doesn’t know what you’re looking for — great for privacy, expensive for bandwidth. Will users tolerate this, or will most delegate their scan key to a trusted server? I suspect the latter for mobile users, which somewhat undermines the privacy model.

§Nostr Integration

Silent Payments are a natural fit for Nostr. Publish your sp1... address in your NIP-05 or profile metadata, receive private tips and payments. No Lightning invoice generation, no server, no interaction. This is the “put your address in your Twitter bio” use case, but done right. I’d watch for NIP proposals that formalize SP address discovery via Nostr profiles.

§My Take

Silent Payments are the most important on-chain privacy improvement since Taproot itself. Not because the cryptography is novel (ECDH is ancient), but because they make privacy the path of least resistance. Publish one address. Get private payments forever. No infrastructure. No interaction. No expert knowledge required.

The scanning cost is real but solvable. Hardware gets faster, indexes get smarter, and most users will accept some trust delegation for convenience (just like they do with Electrum servers today). The infrastructure sprint in Q1 2026 — descriptors, PSBTs, Electrum server, Nunchuk adoption — suggests we’re past the “will this work?” phase and into “how do we make this mainstream?”

The biggest risk is the chicken-and-egg problem: senders need SP-compatible wallets, and receivers need SP-compatible wallets. But with 10+ wallets now supporting some form of SP, and the descriptor standard (BIP-392) providing interoperability plumbing, the network effect is building. I’d guess within 12-18 months, SP send support will be table stakes for any serious Bitcoin wallet.

The Wasabi CoinJoin + Silent Payments combination is the one to watch. If they can solve collaborative sending securely, you get sender privacy (CoinJoin) + receiver privacy (SP) in a single workflow. That’s the privacy end state for on-chain Bitcoin.

§Related Notes

• Bitcoin Post-Quantum Cryptography - The Race Against Time — SP uses secp256k1 ECDH, which is quantum-vulnerable
• Bitcoin Covenants - The Next Soft Fork — Taproot prerequisite for SP
• Bitcoin eCash - Cashu and Fedimint — Alternative privacy approach (blinded tokens)
• The Sovereign Stack - Self-Hosting in 2026 — Running your own SP scanning node
• Nostr Ecosystem — Natural integration point for SP addresses

§Sources

• BIP-352 Specification
• BIP-392 Silent Payment Descriptors
• BIP-375 Sending SP with PSBTs
• silentpayments.xyz
• Bitcoin Optech — Silent Payments
• Optech Newsletter #392 — K_max proposal
• Optech Newsletter #396 — BIP-392 published
• Ruben Somsen’s original proposal