bip bip-392 silent-payments privacy descriptors wallets

BIP392 Merged: Silent Payments Get Standardized Descriptor Support

Schneehoppli · · 8 min read
BIP392 Merged: Silent Payments Get Standardized Descriptor Support

On March 5, 2026, BIP392 was merged into the Bitcoin Improvement Proposals repository. This marks the first Silent Payments companion BIP to reach merge status, and it matters for anyone who cares about Bitcoin privacy tooling.

Silent Payments let you publish a single, reusable address that generates unique on-chain outputs for every payment you receive. No address reuse, no linkability, no on-chain notification transactions. The catch? Your wallet needs to scan the blockchain to find payments meant for you. It’s a meaningful privacy improvement, but it comes with technical complexity.

BIP392 doesn’t change how Silent Payments work. What it does is define a standardized way to represent Silent Payment wallets using output script descriptors, the same format Bitcoin Core, Sparrow, and hardware wallets use for traditional addresses. This is infrastructure work, but good infrastructure is how experimental features become widely adopted.

What are output script descriptors?

Before we talk about BIP392, we need to understand what problem descriptors solve.

Output script descriptors, formalized in BIP380, are standardized strings that contain all the information a wallet needs to derive addresses and track payments. Think of them as a precise recipe: they tell a wallet exactly how to create the scripts that lock funds on-chain.

Before descriptors, wallets stored keys in various incompatible formats. Moving a wallet from Bitcoin Core to a hardware device or from Electrum to Sparrow often required manual export/import processes with unclear semantics. Descriptors fix this by providing a single, unambiguous language for describing how addresses are derived.

A descriptor for a native SegWit address looks like this:

wpkh([deadbeef/84h/0h/0h]xpub6CUGRUonZSQ4TWt...)

This tells any compatible wallet: “Generate pay-to-witness-pubkey-hash addresses using this extended public key, following the BIP84 derivation path.”

Descriptors enable wallet portability. Import a descriptor from Bitcoin Core into a hardware wallet, and both will generate the same addresses. Export a watch-only descriptor to an air-gapped device, and it can monitor payments without holding private keys. This is why BIP392 matters: it brings Silent Payments into the same interoperable framework.

What are silent payments?

Silent Payments, specified in BIP352, solve a fundamental Bitcoin privacy problem: address reuse.

When you give someone a Bitcoin address, every payment to that address is publicly linked on the blockchain. Anyone analyzing the chain can see all the payments, sum them up, and track when funds move. This degrades privacy for both sender and receiver.

Silent Payments change this. Instead of handing out unique addresses manually (which is tedious and error-prone), you publish a single static Silent Payment address. This address is roughly 117 characters long and consists of two public keys: a scan key and a spend key.

When someone sends to your Silent Payment address:

  1. They use the private keys from their transaction inputs
  2. They perform an Elliptic Curve Diffie-Hellman operation with your scan key
  3. They derive a unique taproot output using the shared secret
  4. You scan the blockchain, perform the same operation using your scan private key, and identify outputs meant for you

The result: every payment generates a completely unique on-chain address. An outside observer cannot tell which payments belong to you, and cannot link multiple payments together, even if they all went to the same Silent Payment address.

The tradeoff? Scanning. Unlike traditional wallets that only check the UTXO set for known addresses, Silent Payment receivers must scan every transaction with taproot outputs. For full node users, this is manageable. For light clients, it’s an open research problem (more on that later).

Silent Payments also support a two-key design. You can keep your spend key in cold storage and only expose the scan key to an online device. The online device can detect payments but cannot spend them, which is a meaningful security improvement for high-value wallets.

What BIP392 defines

BIP392, authored by Craig Raw (creator of Sparrow Wallet), introduces a new descriptor type called sp() that allows wallets to represent Silent Payment addresses using the same descriptor framework as traditional Bitcoin addresses.

It defines two new key expression formats:

spscan encodes a watch-only configuration: the scan private key and spend public key. A wallet with this can scan for payments but cannot spend them.

Example:

spscan1qg3pk34hd8hkz2cq9kp30zqv6lz9nm06u2dazmrmq4rgfp84kemwsyxh6vlx0970ker49fqxx492gujl3y65uxp6dwd3lvngcgu9t5fljfww3ah

spspend encodes a full wallet: both scan and spend private keys. A wallet with this can scan and spend.

Example:

spspend1qg3pk34hd8hkz2cq9kp30zqv6lz9nm06u2dazmrmq4rgfp84kemwspy0n42kc0memf6zahf94p9xzc73au4c9v5g2dufq6u3xfr0fyqc82kukk

Both formats use Bech32m encoding with a human-readable prefix (spscan or spspend for mainnet, tspscan or tspspend for testnet). This makes it immediately obvious what kind of key you’re looking at, which matters for non-developers managing backups.

The sp() descriptor can be used in two ways:

Single-argument form:

sp(spscan1q...)
sp(spspend1q...)

Optionally with key origin information:

sp([deadbeef/352h/0h/0h]spscan1q...)

Two-argument form:

sp(SCAN_PRIVATE_KEY, SPEND_KEY)

The first argument must be a private scan key (WIF, xprv, etc.). The second can be any key expression from BIP380, including public keys, extended keys, or even advanced constructs like musig() for MuSig2 aggregate keys (per BIP390).

Examples:

sp(L4rK1yD..., 0260b2003c...)  # WIF scan key, public spend key (watch-only)
sp([deadbeef/352h/0h/0h]xprv.../0h, xpub.../0h)  # Extended keys (watch-only)
sp(L4rK1yD..., musig(03dff1d77..., 023590a94...))  # Scan key + MuSig spend key

The two-argument form provides maximum flexibility for advanced setups, including multisig spend keys or collaborative custody arrangements.

When combined with sender input public keys (as defined in BIP352), the sp() descriptor produces BIP341 taproot outputs. These outputs are indistinguishable from other taproot outputs on-chain, preserving the privacy property that Silent Payment outputs blend into the broader taproot anonymity set.

Why this matters

Pull request #2047, which added BIP392 to the repository, was opened on December 3, 2025, and merged on March 5, 2026, by @murchandamus. The PR generated 50 comments over three months of review, covering everything from encoding choices to philosophical debates about what belongs in a descriptor.

The merge is significant for three reasons:

First, it’s the first Silent Payments companion BIP to reach merge status. BIP352 (the core Silent Payments protocol) has been finalized for some time, but BIP392 signals growing ecosystem maturity around the infrastructure needed to actually use Silent Payments in production wallets.

Second, it solves a real interoperability problem. Before BIP392, wallets implementing Silent Payments had no standardized way to export or import Silent Payment wallet configurations. This meant each wallet would likely invent its own format, creating the same fragmentation problem that descriptors originally solved for traditional addresses. BIP392 prevents that outcome.

Third, it lowers the barrier for descriptor-based wallets to add Silent Payment support. Wallets that have invested heavily in descriptor infrastructure (Bitcoin Core, Sparrow, hardware wallets via HWI) can now support Silent Payments by implementing a single new descriptor type rather than building entirely custom wallet formats.

The PR discussion surfaced some interesting technical debates. One recurring theme: should descriptors include metadata like wallet birthday (the block height when the wallet was created)? Birthday metadata allows a wallet to skip scanning blocks before the wallet existed, which is a significant optimization for Silent Payments.

Descriptor purists argued that descriptors should only encode what is necessary to generate output scripts, and birthday is purely an optimization. Craig Raw countered that if it’s practically impossible to use Silent Payments without birthday metadata (due to unbounded scanning costs), then it becomes necessary data.

This debate led to a follow-up proposal for descriptor annotations, covered in Bitcoin Optech Newsletter #394. Annotations would allow appending metadata like sp(...)#checksum?bh=850000 (birthday height 850,000) without modifying the core descriptor spec. This is still under discussion and may become its own BIP.

Current adoption

As of early 2026, Silent Payments are still experimental. According to the Silent Payments wallet tracker (last updated February 23, 2026), the following wallets support sending to Silent Payment addresses:

  • Sparrow Wallet (added in v2.3.0)
  • BlueWallet
  • Cake Wallet
  • Wasabi Wallet
  • Nunchuk Wallet
  • BlindBit Desktop
  • BitBox (software)
  • Shakesco Wallet

Fewer wallets support receiving Silent Payments, which requires scanning infrastructure:

  • Cake Wallet
  • Dana Wallet
  • BlindBit Desktop
  • Silentium (proof-of-concept, experimental)

Only one hardware wallet currently supports Silent Payments: the BitBox02, which supports both sending and receiving.

Sparrow’s involvement here is worth noting. Craig Raw, who authored BIP392, is also Sparrow’s creator. Sparrow added sending support for Silent Payments in early 2025, and the descriptor work in BIP392 positions Sparrow (and other descriptor-based wallets) to add full receiving support using standardized formats.

What comes next

BIP392’s merge is a milestone, but several open questions remain.

Light client support is the biggest challenge. Scanning every transaction with taproot outputs is feasible for full nodes but impractical for mobile wallets. BIP352 outlines several approaches (tweak data indices, BIP158 filters, out-of-band notifications), but no dominant solution has emerged. Until light clients can efficiently scan for Silent Payments without compromising privacy or relying on trusted third parties, adoption will be limited to full-node users.

Bitcoin Core integration is a coin flip. Core’s descriptor wallet infrastructure is well-suited for sp() support, but as of early 2026, no PR exists. Core developers have historically prioritized consensus and P2P work over application-layer features, so Silent Payment support may come from other wallets first.

Hardware wallet adoption requires firmware updates to support BIP352 cryptographic operations, PSBT extensions for communicating Silent Payment metadata (defined in BIP375), and descriptor parsing for sp() expressions. BitBox02 has already done this work; broader hardware wallet support depends on whether users demand the feature.

The real test for Silent Payments is ecosystem adoption. For the technology to be widely useful, both sending and receiving wallets must support it. As of early 2026, sending support is more common than receiving support, which suggests wallet developers are testing the waters before committing to full scanning infrastructure.

Silent Payments face a classic chicken-and-egg problem: receivers won’t adopt them if senders don’t support sending, and senders won’t prioritize support if few receivers use them. BIP392 doesn’t solve this, but standardization removes one barrier. If Sparrow (and potentially other wallets) ship full BIP392 support in the coming months, that could be the tipping point.

The bottom line

BIP392 is infrastructure work. It doesn’t make Silent Payments faster, cheaper, or easier to use. What it does is make Silent Payments interoperable with the rest of Bitcoin’s wallet ecosystem.

For privacy-conscious bitcoiners running full nodes, Silent Payments offer a meaningful upgrade: static addresses without address reuse, no on-chain notification transactions, and protection for both sender and receiver. The scanning tradeoff is real, but manageable if you’re already running a node.

For the broader ecosystem, BIP392 is a signal that Silent Payments are maturing from experimental feature to production-ready technology. Whether that translates into widespread adoption depends on wallet developers, light client solutions, and whether users are willing to accept the complexity in exchange for better privacy.

Good tooling doesn’t guarantee adoption, but bad tooling guarantees failure. BIP392 is good tooling. The rest is up to the wallets.

Sources: BIP392: Silent Payment Output Script Descriptors, GitHub PR #2047: Add BIP 392, BIP352: Silent Payments, BIP380: Output Script Descriptors General Operation, BIP390: musig() Descriptor Key Expression, BIP341: Taproot, BIP350: Bech32m, BIP375: PSBT Extension for Silent Payments, Bitcoin Optech Newsletter #394, Bitcoin Optech: Silent Payments Topic Page, Bitcoin Optech: Output Script Descriptors Topic Page, Silent Payments Wallet Support Tracker. Wallet adoption data as of February 23, 2026; BIP merge as of March 5, 2026.