Silent Payments: Stealth Addresses for Bitcoin

Every time you share a Bitcoin address publicly, you create a permanent link between your identity and every payment sent to that address. Donation pages, tip jars, and published payment endpoints all suffer from this problem: anyone can look up the address on a block explorer and see every incoming transaction, the total balance, and where funds eventually move. Silent payments, specified in BIP 352, solve this by letting senders derive a unique on-chain address for every payment using a single static identifier from the receiver: no interaction required, no on-chain overhead added.

The Address Reuse Problem

Bitcoin's recommended practice is to generate a fresh address for every payment. This works well in interactive scenarios where a wallet can hand a new address to each sender. But many real-world use cases demand a static, publishable payment identifier: open-source projects accepting donations, merchants displaying a QR code, or anyone who wants to receive payments without being online to generate addresses.

When multiple payments arrive at the same address, the privacy damage compounds. Chain analysis firms apply the common-input-ownership heuristic to cluster addresses. Adversaries can execute dust attacks, sending tiny amounts to known addresses and then monitoring when those UTXOs are spent alongside others, mapping out wallet holdings. Address reuse harms not only the receiver but also every sender, since payment relationships become visible to the public.

Why fresh addresses aren't enough: Generating a new address per payment requires interaction. The receiver must be online, run a server, or use a protocol like BOLT12 offers to hand out addresses dynamically. Silent payments eliminate this requirement entirely.

How Silent Payments Work

The core mechanism is Elliptic-Curve Diffie-Hellman (ECDH): a well-established cryptographic technique for deriving a shared secret between two parties. In silent payments, the sender uses their transaction input keys and the receiver's published scan key to compute a shared secret. That secret tweaks the receiver's spend key to produce a unique Taproot output address that only the receiver can spend.

Key Setup

The receiver generates two keypairs derived from their HD wallet at the BIP 352 derivation path (m/352'/0'/0'/):

• Scan keypair: b_scan (private) and B_scan (public), used for detecting incoming payments
• Spend keypair: b_spend (private) and B_spend (public), used for actually spending received funds

The receiver publishes a silent payment address containing both public keys. This address uses Bech32m encoding with the sp human-readable prefix (mainnet) or tsp (testnet), resulting in addresses that start with sp1q... and are approximately 117 characters long.

Sending a Payment

When Alice wants to pay Bob's silent payment address, her wallet performs these steps:

1. Sum all eligible input public keys: A = A_1 + A_2 + ... + A_n
2. Compute an input hash using the smallest outpoint and the summed key: input_hash = SHA256("BIP0352/Inputs" || outpoint_L || A)
3. Derive the ECDH shared secret: ECDH = input_hash * a_sum * B_scan
4. Generate the output key: P_0 = B_spend + SHA256(ECDH || 0) * G
5. Use P_0 as the Taproot output key for the payment

The input_hash mechanism is critical: even if Alice reuses the same public key in a later transaction, the different outpoint produces a different hash, which produces a different output address. This prevents address linkability across transactions from the same sender.

Receiving: The Scanning Requirement

Bob cannot simply check a list of known addresses against new blocks. Instead, his wallet must scan every transaction that meets certain criteria: it contains at least one Taproot output and has at least one eligible input type (P2TR, P2WPKH, P2SH-P2WPKH, or P2PKH).

For each eligible transaction, Bob's wallet extracts the summed input public keys, computes the same ECDH shared secret using his scan private key, derives the expected output key, and checks whether it matches any Taproot output in the transaction. If it matches, Bob has found a payment: he can derive the full spending key as b_spend + SHA256(ECDH || k).

Scan key delegation: The scan key only detects payments. It cannot spend them. This separation allows the receiver to delegate scanning to a server or service without giving up control of funds. The spend key remains in cold storage or on a signing device.

Silent Payment Address Format

The address encodes 66 bytes of payload: two 33-byte compressed public keys (B_scan || B_spend), prepended by a version byte. Version 0 addresses start with sp1q on mainnet. The spec reserves versions 1 through 30 for forward-compatible extensions and version 31 for backwards-incompatible changes.

Labels

BIP 352 includes a labeling mechanism that lets the receiver generate multiple distinct silent payment addresses from the same root keys. A label modifies the spend key: B_m = B_spend + SHA256(b_scan || m) * G, where m is an integer. This allows categorizing payments (for example, separating donations from invoice payments) without any additional scanning overhead, since the scan key remains the same.

Label m = 0 is reserved for change outputs, enabling wallets to send change back to themselves using the same silent payment protocol.

Comparison to Prior Stealth Address Proposals

Silent payments are not the first attempt at reusable payment codes for Bitcoin. Two notable predecessors shaped the design space.

Peter Todd's Stealth Addresses (2014)

The original stealth address proposal, formalized around 2014 and partially implemented in Dark Wallet, used OP_RETURN outputs to signal payment metadata. When Bitcoin Core reduced OP_RETURN data to 40 bytes, the scheme broke. Each payment required an extra on-chain output carrying the ephemeral public key, adding cost and creating a detectable pattern.

BIP 47 Payment Codes (2015)

Justus Ranvier's BIP 47 introduced reusable payment codes that require a one-time notification transaction per sender-receiver pair. After the notification, the sender can derive unlimited unique addresses. The key drawback: the notification transaction is publicly identifiable and creates a permanent on-chain link between sender and receiver payment codes. If either party's identity is later associated with their payment code, the entire relationship is exposed.

BIP 352's key innovation is eliminating the notification step entirely. By deriving the shared secret from the sender's existing transaction inputs, no extra data needs to be published on-chain. The tradeoff is that the receiver must actively scan the blockchain to find payments.

Implementation Status

BIP 352 reached version 1.0.0 in May 2024 when it was merged into the bitcoin/bips repository. The specification was authored by Josie Baker and Ruben Somsen and carries a status of "Complete." No consensus changes are required: any wallet can implement silent payments independently.

Bitcoin Core integration is progressing across several pull requests: core BIP 352 primitives (#28122), wallet sending (#28201), wallet receiving (#32966), and a dedicated silent payments index for light wallet support (#28241). A corresponding secp256k1 module provides the underlying cryptographic operations.

The Scanning Tradeoff

The most significant challenge with silent payments is the computational cost of scanning. Unlike standard Bitcoin addresses, where a wallet simply checks its list of known addresses against block data, a silent payment wallet must perform an ECDH computation for every eligible transaction in every block.

Full Node Scanning

A full node scanning the entire blockchain from genesis takes roughly 8 to 12 hours on reference hardware. Wallet birthday optimization helps: users recovering a wallet only need to scan blocks after their wallet creation date, significantly reducing the initial sync.

Light Client Challenges

For light clients, scanning is harder. The wallet needs 33 bytes of tweak data (the summed, tweaked input public key) per eligible transaction. Current estimates put this at roughly 7 to 12 kilobytes per block, or 30 to 50 megabytes per month. A light client protocol is under active discussion on Delving Bitcoin.

One approach combines silent payments with BIP 158 compact block filters: the client computes candidate output scriptPubKeys from the tweak data, then checks them against the filter. On a match, it downloads the full block. This minimizes bandwidth but still requires the tweak data to be served by someone.

Trust tradeoff for mobile wallets: Server-assisted scanning can reduce detection time to seconds, but the server learns which transactions belong to the user. The scan key delegation model offers a middle ground: the server can detect payments but cannot spend them. Full privacy requires running your own node.

Taproot Integration

Silent payments generate exclusively P2TR (Taproot) outputs. This is a deliberate design choice: limiting outputs to a single type maximizes the anonymity set. Silent payment outputs are indistinguishable from regular Taproot transactions on-chain, a property known as steganographic privacy.

The interaction with Taproot's x-only public keys (BIP 340) requires careful handling. Taproot uses 32-byte x-only keys with an assumed even y-coordinate. When a sender's input is a Taproot UTXO, the private key may need negation to ensure the corresponding public key has even parity. Both sender and receiver must agree on parity for the ECDH shared secret to match.

Multi-Party Signing

For wallets using MuSig2 or FROST threshold signatures, the ECDH step must be performed collaboratively. Each signer computes a partial ECDH share, and the shares are summed. BIP 375 specifies how to handle this in PSBTs, including DLEQ (Discrete Logarithm Equality) proof fields that let each signer verify others computed their shares honestly.

Recent Developments

The silent payments ecosystem has matured since the initial specification:

• BIP 375 was merged in 2025, specifying how to send silent payments using PSBTs with DLEQ proof fields for hardware wallet compatibility
• BIP 374 defines the underlying DLEQ proof format needed for multi-signer silent payment transactions
• BIP 352 reached version 1.0.2 in July 2025, clarifying edge cases where SHA256 output equals zero or exceeds the secp256k1 curve order
• Matt Corallo's DNS-based human-readable payment instructions proposal enables mapping domain names to silent payment addresses via DNSSEC-signed TXT records
• Post-quantum compatibility research by Jesse Posner on Delving Bitcoin indicates that quantum-resistant signature algorithms can support BIP 352-style protocols

Privacy on Layer 2: A Different Approach

Silent payments address a fundamental on-chain problem: how to receive payments to a static identifier without creating linkable outputs. But this problem is specific to the UTXO model, where every payment creates a publicly visible output tied to an address.

Spark takes a different approach to payment privacy. Transfers on Spark update ownership of existing Bitcoin without creating new on-chain outputs at all. When Alice sends to Bob on Spark, the same on-chain UTXO remains in place: what changes is the cryptographic key that authorizes spending. There is no address to reuse because there are no addresses in the on-chain sense. Each transfer produces a fresh key configuration through the operator network's FROST threshold signing process.

This means the address reuse problem that silent payments solve on Layer 1 does not exist on Spark. The two approaches are complementary: silent payments improve on-chain privacy for scenarios that require base-layer settlement, while Layer 2 protocols like Spark avoid the problem by keeping transfers off-chain entirely.

Tradeoffs Summary

Silent payments represent a meaningful privacy improvement for Bitcoin, but they come with real costs that developers and users should understand:

• Scanning cost scales linearly with blockchain size and transaction volume
• Light client support remains an open research problem with no production-ready solution
• Wallet recovery requires rescanning the chain from the wallet birthday, unlike standard derivation-path-based recovery with gap limit detection
• Only Taproot inputs can serve as ECDH contributors, so senders must hold Taproot UTXOs (or other eligible input types)
• The privacy benefit depends on adoption: the larger the set of silent payment transactions, the harder it becomes for observers to identify which Taproot outputs are silent payments

For developers building on Bitcoin, silent payments are worth watching. The specification is complete, wallet adoption is growing, and the protocol addresses a real gap in Bitcoin's privacy toolkit. For those building applications that need private, scalable payments today, the Spark SDK offers a complementary path: instant transfers with inherent privacy and no scanning overhead. Explore the Layer 2 comparison to understand where each approach fits.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.