Timechain Wiki

Stealth addresses and Silent Payments

16 min read

Stealth addresses and Silent Payments are recipient-side privacy primitives: a receiver publishes a single static identifier ("payment code") from which senders derive a unique fresh address per payment without further interaction. The cryptography uses elliptic-curve Diffie-Hellman (ECDH) between the sender's transaction key and the receiver's payment code, producing a per-payment address only the receiver can identify and spend. Silent Payments (BIP-352), finalised 2023-2024, is the canonical modern implementation; it succeeds earlier proposals (Peter Todd's 2014 BIP-47 reusable payment codes; Monero-style stealth-address designs). BIP-352 uses Schnorr signatures (via Taproot) and produces standard P2TR outputs indistinguishable from ordinary Taproot transactions to chain-analysis. The cost is per-transaction recipient-side block scanning. As of 2026, wallet support has expanded (Cake Wallet; Sparrow Wallet, which shipped sending in v2.4.0 and receiving — including airgapped hardware signers — in v2.5.0, May 2026; Silent-Payments-enabled Bitcoin Core forks) but remains a minority of wallet software.

Why this note matters

Stealth addresses and Silent Payments address a privacy gap that the rest of the stack does not: recipient-side privacy without operational burden. The note matters because:

  • They eliminate the address-reuse failure mode that Address reuse and chain analysis identifies as the foundational threat, at zero operational cost to the recipient.
  • They enable public-payment endpoints (donation pages, “tip jars,” service-fee receipts, subscription billing) without the privacy catastrophe that static address reuse creates.
  • They are complementary rather than substitutionary to CoinJoin and PayJoin — the privacy primitives address different parts of the threat surface. A complete privacy practice uses all three.
  • BIP-352’s 2024 finalization is the most significant Bitcoin privacy-protocol development of the post-2020 period; documenting its current state and adoption trajectory matters for holders evaluating the privacy stack.
  • The legacy stealth-address lineage (Peter Todd’s BIP-47, Monero’s stealth addresses) influenced the design and provides comparison context that helps holders understand what is new vs. continuous.

The defensible position: Silent Payments will likely become the default for payment endpoints over the 2026-2030 period as wallet support expands. Holders should track adoption and adopt as their wallet supports it; receivers running public payment endpoints should prioritise Silent Payments over static address reuse as soon as practical.

What recipient-side privacy means

In ordinary Bitcoin payments, the recipient publishes an address. The sender pays to that address. If the same address is published for multiple payments, all those payments go to the same on-chain endpoint — instant cluster identification.

The standard defence is address rotation: the recipient generates a fresh address for every payment, communicates it out-of-band to the sender, and the sender pays to it. This works for one-off interactions (an invoice email, a checkout flow) but breaks down for:

  • Public-facing payment endpoints: a donation page, “tip jar,” fixed business-receivable address.
  • Subscriptions and recurring payments: a service that charges the customer periodically can’t easily rotate addresses without per-payment coordination.
  • Person-to-person payments outside an active conversation: a friend paying you back next month shouldn’t need to ask you for a fresh address.

Recipient-side privacy primitives solve this by allowing the receiver to publish one static identifier from which senders derive unique fresh addresses for each payment, without further interaction.

The key cryptographic property: only the receiver can identify and spend the derived addresses. The sender derives the address, pays to it, but cannot link payments together (and cannot link them to other payments going to the same recipient).

The lineage: stealth-address proposals (2012-2022)

Peter Todd’s BIP-47 reusable payment codes (2015)

BIP-47 (proposed by Justus Ranvier, refined with Peter Todd) introduced the concept of a “payment code” — a single static identifier from which senders derive per-payment addresses via ECDH.

The mechanism:

  • The recipient publishes a payment code (effectively, an extended public key) — typically as a string starting with “PM…” or as a QR code.
  • The sender generates an ephemeral key, performs ECDH between their ephemeral key and the recipient’s payment code, and derives a fresh address.
  • The sender includes a “notification transaction” that signals to the recipient “I’m going to start paying you.” After the notification, the recipient scans for derived addresses on each new payment.

BIP-47’s properties and limitations:

  • Notification transaction is the privacy weakness: every BIP-47 payment relationship is signalled on-chain via a notification transaction. Chain-analysis can identify these notifications and cluster sender-recipient relationships.
  • Samourai’s implementation: Samourai Wallet was the primary BIP-47 deployer. The implementation was operational but had limited interoperability with non-Samourai wallets.
  • Adoption gap: BIP-47 never achieved meaningful adoption outside the Samourai ecosystem; the notification-transaction weakness and the wallet-interop gap limited it.

When Samourai shut down in 2024, BIP-47 effectively lost its principal active deployment. The protocol still exists but is no longer the active recipient-side primitive in Bitcoin.

The Monero stealth-address tradition

Monero (launched 2014) implemented stealth addresses as a core protocol feature. Every Monero transaction sends to a stealth address derived from the recipient’s published payment information; the protocol mandates this rather than treating it as opt-in.

The Monero design influences:

  • Bitcoin’s stealth-address proposals draw on the Monero design tradition for the basic ECDH-derivation mechanism.
  • Monero’s mandatory privacy model is structurally different from Bitcoin’s opt-in approach, but the cryptography is similar.
  • Academic and practitioner work on Monero stealth-address properties informs Bitcoin’s parallel work.

Monero receives no substantive treatment here — Bitcoin, not the broader cryptocurrency space, is the subject — but acknowledging the design-lineage debt is honest.

Other proposals

Various other stealth-address proposals existed across 2012-2022 (van Saberhagen’s CryptoNote-style designs, various academic constructions). Most did not achieve deployment in Bitcoin; the lineage is included for completeness rather than because the proposals are currently relevant.

BIP-352: Silent Payments (2024 finalization)

Silent Payments (BIP-352, authored by Ruben Somsen, Josibake, and contributors; finalised 2023-2024) is the current state-of-the-art recipient-side privacy primitive for Bitcoin. The design fixes BIP-47’s principal weakness (the notification-transaction leak) while maintaining the same recipient-side operational properties.

The mechanism

The recipient publishes a static “silent payment address” — typically encoded as a string starting with “sp1…” or as a QR code. This address contains the recipient’s scan key and spend key (two separate Schnorr public keys).

For each payment:

  1. The sender constructs a normal Bitcoin transaction with one or more inputs and a Taproot (P2TR) output paying to an address derived from ECDH between the sender’s input keys and the recipient’s silent payment address.
  2. No notification transaction is needed: the derivation uses the sender’s transaction inputs as the ephemeral key material. The notification is embedded in the payment transaction itself.
  3. The output is a standard P2TR: indistinguishable from ordinary Taproot outputs to chain-analysis.

Recipient-side scanning: the recipient must scan every block on the Bitcoin network for outputs derived from their silent payment address. For each new block, the recipient performs ECDH between every transaction’s input keys and their scan key to identify payments addressed to them.

The scanning is computationally bounded:

  • Bitcoin produces approximately one block every 10 minutes; each block contains ~1500-3000 transactions.
  • For each transaction, the recipient checks whether any output is addressed to them. The check is one ECDH operation per transaction’s input set.
  • Total cost: roughly 1500-3000 ECDH operations per 10 minutes — negligible on modern hardware.
  • For wallets that prefer not to scan continuously, a backend service can perform scanning and notify the wallet. This trades some privacy (the backend learns which payments are addressed to which wallet) for operational simplicity.

What BIP-352 defeats

Address-reuse failure at the recipient endpoint: there is no “static address” — every payment goes to a fresh per-payment address that chain-analysis cannot cluster.

Notification-transaction leakage (the BIP-47 weakness): no notification transaction exists. The payment itself contains the privacy-preserving derivation.

Recipient-cluster identification by counterparty: a chain-analysis firm observing many payments to one silent payment address can no longer cluster them because the derived addresses are distinct and not on-chain-linkable.

Public-endpoint privacy loss: a public-facing silent payment address can receive arbitrary payments without compromising the recipient’s privacy. Donation pages, “tip jars,” subscription billing — all work without privacy catastrophe.

What BIP-352 does not defeat

Sender-side identity-resolution: the sender’s input UTXOs still cluster with the sender’s previous transactions. The recipient doesn’t see the sender’s identity through Silent Payments; chain-analysis firms still cluster the sender’s wallet.

Input-side CIOH: if the sender’s input UTXOs were already chain-analysis-clustered, the CIOH still applies. Silent Payments protects the recipient endpoint, not the sender’s input clustering.

Total transaction volume analysis: chain-analysis can still see the total value of payments and the recipient’s claim activity (when the recipient spends post-receipt). The privacy benefit is recipient-side anti-clustering, not blanket privacy.

Pre-Silent-Payments history: a recipient who reused addresses for years before switching to Silent Payments has a leaked history; Silent Payments protects forward, not backward.

KYC and off-chain identity channels: same as for all on-chain privacy primitives — the off-chain identity-resolution surfaces (KYC, dark-market data, surveillance integrations) are unaffected.

What it changes for the privacy stack

Silent Payments materially shifts the privacy stack in two ways:

  1. Address-reuse hygiene becomes automatic at the recipient endpoint: the recipient publishes one identifier; the protocol handles per-payment fresh addresses. The largest privacy failure mode for receivers is eliminated by adoption alone.

  2. Public-payment endpoints become privacy-respecting: donation pages, subscription bills, business receivables can use a single Silent Payments identifier without privacy catastrophe. The collective privacy floor for public payments rises substantially.

A holder who adopts Silent Payments for their public payment endpoints (donation address, tip jar, business receivable) makes a meaningful privacy improvement at near-zero ongoing operational cost.

Operational reality in 2026

Wallet support

  • Cake Wallet — early adopter of Silent Payments for Bitcoin; receiver-side support since 2024.
  • Silent Payments-enabled Bitcoin Core forks — experimental builds with native Silent Payments support; not yet in mainline Bitcoin Core.
  • Sparrow Wallet — full support landed in 2026, the first major desktop wallet to ship it end-to-end: sending to silent payment addresses in v2.4.0 (February 2026, with BIP-375 PSBT fields and DLEQ-proof verification for hardware-wallet signing) and receiving wallets in v2.5.0 (May 2026), including airgapped hardware-wallet signers — meaning Silent Payments can now be received directly to cold storage. Receiving offloads the block-scanning to an SP-capable Electrum server (frigate.2140.dev, auto-selected), the service-backed scanning pattern discussed below; v2.5.2 added SP-specific dust-attack detection.
  • BTCPayServer — community work on Silent Payments for merchant payment endpoints; expected to expand in 2026.
  • Mobile wallets — limited adoption as of 2026; expected to grow as the protocol matures.

The honest read: BIP-352 wallet support is expanding but not yet ubiquitous. A holder who wants to use Silent Payments today can do so with Cake Wallet and selected adjacent tools; mainstream wallet support is still in progress.

Sender-side adoption

For Silent Payments to be useful, the sender’s wallet must support generating payments to silent payment addresses. As of 2026:

  • Cake Wallet — sender-side support
  • Sparrow Wallet — sender-side support since v2.4.0 (February 2026), including hardware-wallet signing via BIP-375
  • Silent Payments-aware wallets — a growing handful
  • Mainline wallet support — limited; tracking development

The sender-side adoption follows the recipient-side adoption; both are growing but neither is dominant in 2026.

Receiver-side scanning costs

The block-by-block scanning is computationally cheap but requires continuous wallet operation or a backend scanning service. Two operational patterns:

  • Self-hosted scanning: the wallet runs on a node or with a node connection and scans every block. Best privacy properties; requires technical setup.
  • Service-backed scanning: the wallet uses a third-party service to scan for payments addressed to its silent payment address. Operationally simple; the backend learns which payments are addressed to the wallet (a privacy degradation).

For substantial-balance silent-payment use, self-hosted scanning is preferable. For small-balance use, service-backed scanning is operationally tractable.

When Silent Payments make sense

  • Public-facing payment endpoints (donation pages, “tip jars,” business receivables, public-key-identifier subscriptions) — the highest-value use case.
  • Long-running payment relationships where periodic payments would otherwise reuse an address.
  • Recipient-side privacy-respecting services that want to offer customers a single endpoint without privacy catastrophe.

When Silent Payments don’t (yet) make sense

  • One-off payments between people with active out-of-band communication — fresh-address derivation via BIP-21 URI is operationally equivalent at lower wallet-complexity cost.
  • Wallets without support — the sender’s or receiver’s wallet must support the protocol; in 2026 this is the principal gating constraint.
  • High-frequency micro-payments — Lightning is better-suited (see Lightning privacy properties).

Counter-arguments and tensions

”Silent Payments are too new; wallet adoption is too limited for this to be operationally meaningful”

The argument: As of 2026, Silent Payments adoption is limited to a handful of wallets. Most senders cannot pay to a silent payment address. Most receivers cannot generate one. The protocol is interesting but not yet operationally meaningful.

Response: Largely true for 2026 but the trajectory is favorable. The protocol finalised in 2024; wallet adoption typically lags protocol finalization by 1-3 years; major-wallet support is expected in 2026-2028. A holder evaluating Silent Payments today should treat it as “track adoption; deploy as wallet support matures” rather than “deploy immediately.” Receivers running public endpoints should plan migration to Silent Payments as part of their 2026-2027 roadmap.

”Recipient-side scanning is a denial-of-service vector”

The argument: An adversary could spam silent payment-style outputs to a recipient’s published silent payment address, forcing the recipient to scan and process huge volumes of bogus candidate payments. This is a structural denial-of-service vulnerability.

Response: The concern is real but bounded. Scanning is computationally cheap (one ECDH operation per transaction); the worst-case scanning load is bounded by Bitcoin’s per-block transaction count. The DOS exposure is “the recipient must scan every block” which is already true for any holder running a full node. The adversarial cost (paying mining fees for spam outputs) is non-trivial; the spam approach is also visible to the network and chain-analyzable. The protocol’s design accepts this scanning load as the price of recipient-side privacy.

”Backend scanning services are a privacy regression”

The argument: Wallets that outsource scanning to backend services give those services full visibility into which payments are addressed to the wallet. This is a meaningful privacy regression from self-hosted scanning.

Response: True. The service-backed scanning model is operationally easier but privacy-worse than self-hosted scanning. The realistic mitigation: end-users should self-host scanning when their threat model supports it; service-backed scanning is a stopgap that should be flagged as such, not marketed as full Silent Payments privacy. Wallet design choices matter here; the better wallets will make the trade-off explicit and let users choose.

”BIP-352 doesn’t break chain-analysis at the transaction level”

The argument: A Silent Payments transaction looks like an ordinary Taproot transaction. Chain-analysis can still apply CIOH to the sender’s inputs and identify the sender’s cluster. The privacy benefit is entirely recipient-side; the sender’s cluster is just as exposed as before.

Response: Correct. Silent Payments protects recipient identity-clustering; it does not protect sender identity-clustering. The framing in this note treats it as a recipient-side primitive specifically. For sender-side privacy, the holder should use CoinJoin or PayJoin or both. The privacy primitives are complementary: Silent Payments for receiver; CoinJoin/PayJoin for sender. A complete privacy practice uses both.

”BIP-47 was the right design; Silent Payments adds complexity for marginal privacy gain”

The argument: BIP-47’s notification-transaction approach was operationally simpler. The notification leakage is real but bounded; Silent Payments adds significant complexity (block-by-block scanning, new cryptographic primitives) for what is mostly an improvement on a marginal privacy property.

Response: Substantively wrong. The notification-transaction leakage is not marginal — it directly clusters every sender-recipient relationship that uses BIP-47. Chain-analysis firms could (and reportedly did) maintain large databases of notification transactions, effectively mapping the Bitcoin BIP-47 user population. Silent Payments eliminates this clustering surface. The added complexity (recipient-side scanning) is significant but bounded; the privacy improvement is substantial. The right trade-off is on the Silent Payments side.

Open questions for further development

  • BIP-352 wallet adoption is the dominant gating factor. Which wallets are likely to add support over 2026-2028, and which are unlikely? A regularly-updated tracking is useful but operationally hard to maintain.
  • The backend-scanning service market is emerging. Which services have demonstrated reliable privacy properties, and how does service-backed scanning compare to self-hosted in the realistic threat models for ordinary holders?
  • Silent Payments interactions with hardware wallets (PSBT support, signing of Silent Payments transactions) are still maturing. What’s the current state and which devices have committed support?
  • BIP-47 will continue to exist in the protocol space. Are there scenarios where BIP-47 is preferred to BIP-352 (e.g., environments where block-by-block scanning is infeasible)?
  • BIP-352 will eventually become the basis for default-recipient-privacy in many Bitcoin payment flows. What’s the realistic timeline for wallet defaults to include Silent Payments as the recommended public-payment-endpoint format?

Canonical sources for this note

BIP specifications:

  • BIP-47 (Reusable Payment Codes) — Justus Ranvier, Peter Todd (2015); the historical proposal
  • BIP-352 (Silent Payments) — Ruben Somsen, Josibake et al. (finalised 2023-2024); the current state-of-the-art

Developmental and community materials:

  • silentpayments.xyz — community-maintained documentation
  • Cake Wallet documentation — Silent Payments operational walkthrough
  • Sparrow Wallet developmental notes
  • BTCPayServer Silent Payments integration discussions

Academic and protocol-design:

  • van Saberhagen — CryptoNote v2.0 Whitepaper (2013) — the original stealth-address protocol lineage
  • Various Bitcoin Stealth Address proposals (BIP-63 et al., pre-BIP-47)
  • Academic literature on Monero stealth address properties (Möser, Heffan, et al.)
  • Schnorr signature work that enables BIP-352 (Taproot deployment 2021)

Practitioner literature:

  • 6102bitcoin’s Bitcoin Privacy Guide — operational walkthrough
  • Bitcoin Q+A podcast — episodes covering Silent Payments
  • Bitcoin Optech newsletter — protocol-update coverage of BIP-352

LegacyCipher synthesis (April 2026) — integrates Silent Payments into the operational privacy stack.

As of 2026-07-15: BIP-352 wallet adoption crossed a meaningful threshold in 2026 — Sparrow shipped sending (v2.4.0, February) and receiving with airgapped hardware-signer support (v2.5.0, May). Track broader wallet defaults over the 2026-2028 period.

Companion Privacy practice notes:

The threat-modeling framework:

Operational practice:

Cryptographic background:

  • Taproot upgrade enables Schnorr-based output structures that BIP-352 uses; see Taproot upgrade

Adjacent thinker pages:

  • Peter Todd — co-author of BIP-47; foundational Bitcoin privacy work

The sub-MOC home:

Graph View

Backlinks