BIP392: Silent Payment Descriptors Finalized for Wallet Integration | Bitcoin Index

Bitcoin privacy got a standardization boost on March 5, 2026, when BIP392 merged into the official Bitcoin Improvement Proposals repository. The specification defines how wallet software should represent silent payment addresses using output script descriptors, solving a critical interoperability problem that had stalled adoption.

If you’re unfamiliar with silent payments, here’s the quick version: they let you publish a static Bitcoin address that doesn’t create on-chain links between payments. Each payment generates a unique output that looks like any other taproot transaction, preserving privacy without requiring sender-receiver interaction. The catch? Receiving wallets must scan the blockchain to detect incoming payments.

BIP392 doesn’t change how silent payments work. It standardizes how wallets store and share the cryptographic keys needed to scan for and spend silent payment outputs. Think of it as defining the backup format that lets you move your silent payment wallet from Sparrow to Bitcoin Core without losing access to funds.

The descriptor problem

Output script descriptors have become Bitcoin’s standard way to represent wallet configurations. Introduced through BIP380-387, they provide machine-readable formats for backup, recovery, and cross-wallet compatibility. Every modern Bitcoin wallet uses them.

Silent payments broke this pattern. Standard descriptors describe outputs using only key material. Silent payment outputs require combining your keys with sender input public keys extracted from blockchain transactions. No existing descriptor type could represent this scanning process.

Without standardization, each wallet implementing silent payments would create incompatible backups. Your Sparrow silent payment wallet backup wouldn’t work in Bitcoin Core. Hardware wallets couldn’t support silent payments without custom formats for each manufacturer.

The sp() descriptor

BIP392 introduces a new sp() descriptor expression with two possible forms:

Single-argument form:

sp(KEY)

Two-argument form:

sp(SCAN_KEY, SPEND_KEY)

The single-argument form uses newly defined key formats called spscan and spspend. These bech32m-encoded strings bundle both scan and spend keys in a single element. The two-argument form lets you specify keys separately, supporting any existing Bitcoin key expression (WIF, xprv, xpub, and even MuSig2 aggregates).

New key formats

spscan (watch-only):

Encodes scan private key + spend public key
Lets you detect incoming payments but not spend them
Example: sp(spscan1q...)

spspend (full wallet):

Encodes scan private key + spend private key
Provides complete wallet functionality
Example: sp(spspend1q...)

Both use bech32m encoding with q version indicators for silent payments version 0. Mainnet prefixes are spscan1q and spspend1q; testnet uses tspscan1q and tspspend1q.

Why bundle keys?

The decision to create spscan and spspend sparked significant technical debate. Andrew Chow, author of most descriptor specifications, argued that concatenating keys into single elements contradicted descriptor philosophy. Existing formats (WIF for private keys, hex for public keys) should have been sufficient.

Craig Raw, BIP392’s author and developer of Sparrow Wallet, countered with user-experience arguments:

Bech32m provides robust error detection for written backups
The format makes key type immediately obvious (scan-only vs. full wallet)
Users already understand the xpub pattern; this follows the same model
Prevents accidentally mixing unrelated scan and spend keys

The debate reflects a fundamental tension in Bitcoin development: technical purity versus user accessibility. Chow maintained that in an ideal world, even xpubs would have been decomposed into separate fields. Raw argued that descriptors are fundamentally user-facing interfaces that should optimize for comprehension and safety.

BIP392 merged with the bundled key formats, suggesting reviewers prioritized usability.

MuSig2 integration

One underappreciated feature of BIP392 is its support for MuSig2 aggregate spend keys via BIP390. You can create a silent payment address controlled by multiple parties without revealing the multisignature setup on-chain:

sp(L4rK1yDtCWekvXuE..., musig(03dff1d77f..., 023590a94e...))

This combines silent payment privacy with collaborative custody arrangements. The blockchain shows only standard taproot outputs; observers can’t distinguish multisig from single-key spending.

What got left out

The original BIP392 proposal included two features that didn’t make it into the final specification:

Birthday metadata: An optional block height argument to reduce scanning burden. If you know your wallet was created at block 800,000, you can skip scanning earlier blocks. Andrew Chow objected that metadata doesn’t belong in descriptors. The feature was removed, though a separate proposal for general descriptor annotations may address this gap.

Labels: BIP352 silent payments support labels, a mechanism for distinguishing payment sources using the same address. The BIP392 GitHub pull request included extensive discussion of label range syntax (1-10, 15, 20-25), but the published specification makes no mention of labels. Either they’ll appear in a future revision, or consensus emerged that labels belong at a different layer.

Current state of adoption

As of March 2026, silent payments have limited but growing wallet support:

Bitcoin Core 28.0+ offers experimental command-line support
Cake Wallet was among the first mobile wallets to implement silent payments
Nunchuk has announced support

BIP392 was only finalized on March 5 and published in Bitcoin Optech Newsletter #396 on March 13, so descriptor-based implementations are still emerging. Sparrow Wallet is the most likely early adopter, given Craig Raw authored the specification, though no public release has been announced.

Scanning remains the bottleneck

BIP392 solves wallet interoperability, but it doesn’t address silent payments’ fundamental challenge: computational cost. Receiving requires scanning every block for potential payments. Light clients face bandwidth and processing constraints that make this impractical on mobile devices.

Potential solutions include:

Third-party scanning services (trust trade-off)
Compact block filters optimized for silent payment detection
Server-assisted scanning with privacy-preserving protocols

Until scanning burden drops, silent payments will remain primarily a desktop wallet feature for users who prioritize privacy over convenience.

Why this matters

Bitcoin privacy tools have historically failed at interoperability. Different wallet implementations create incompatible backups. Users lock themselves into single vendors. Hardware wallet integration stalls because each manufacturer needs custom implementations.

BIP392 breaks this pattern. By defining a standard descriptor format, it creates a foundation for ecosystem-wide silent payment support. Your silent payment backup will work across wallets. Hardware devices can implement one specification instead of negotiating with each wallet developer.

The real impact won’t be visible for months. Wallet developers need time to implement BIP392 support. Hardware vendors need finalized specs before starting engineering work. But once the ecosystem catches up, silent payments gain the same portability advantages that descriptor-based wallets have enjoyed since Bitcoin Core 0.21.

Privacy tools are only useful if people actually use them. Standardization is the path from experimental feature to mainstream adoption.

Sources

Data as of March 19, 2026.