BIP-392: The Boring Infrastructure That Makes Bitcoin Privacy Work | Bitcoin Index

Bitcoin privacy tech has a hype problem. Flashy protocols promise perfect anonymity, get headlines, then fade when real-world friction kills adoption. The unglamorous work that actually enables privacy at scale? That happens quietly, in pull requests like the one Craig Raw merged on March 5, 2026.

BIP-392 defines output script descriptors for silent payments. If your eyes just glazed over, stay with me. This is the infrastructure work that determines whether Bitcoin’s most promising privacy tech becomes an interoperable standard or a fragmented mess of incompatible implementations.

The problem: wallet lock-in

Here’s the scenario BIP-392 prevents: You create a silent payment wallet in Wallet A. It works great. Three years later, you want to switch to Wallet B for better features. You export your backup and… it doesn’t work. Wallet B uses a different format. Your funds are locked in Wallet A’s proprietary structure.

Without standardization, that’s exactly where we were headed. Each wallet would invent its own way to store silent payment keys. Users would be trapped. Backups would be fragile. Recovery would be a nightmare.

BIP-392 solves this by integrating silent payments into Bitcoin’s existing descriptor framework, giving them the same standardized backup and recovery infrastructure that regular Bitcoin wallets have enjoyed since Bitcoin Core adopted descriptors.

Quick context: what are silent payments?

Silent payments (BIP-352) solve a real usability vs. privacy tension. Best practice says you should use a fresh Bitcoin address for every payment (to prevent address reuse from linking your transactions). But that requires generating and sharing a new address each time, which is annoying for donations, recurring payments, or anything where you just want to publish one static address.

Previous solutions like BIP-47 payment codes required expensive notification transactions on-chain. Silent payments skip the notification entirely. You publish one reusable address. Senders use your public key plus their own private key to derive a unique on-chain address via elliptic curve Diffie-Hellman. Every payment lands at a different address. No on-chain linkability. No notification spam.

The trade-off? You have to scan the blockchain to detect payments, which is computationally expensive. But for users who prioritize privacy, that’s an acceptable cost.

Silent payments have been gaining traction since BIP-352 merged in March 2024. Wallets like Cake Wallet, BitBox02, Nunchuk, and (as of early 2026) Sparrow Wallet have added support. But until BIP-392, there was no standard for backing up and restoring these wallets across implementations.

Quick context: what are output script descriptors?

Output script descriptors (BIP-380) are a language for describing Bitcoin output scripts in a standardized, human-readable way. They emerged to solve a similar interoperability problem.

In the early days of hierarchical deterministic wallets, your BIP-39 seed phrase could recover your private keys, but the wallet software still had to guess what kind of addresses you were using (P2PKH? Native SegWit? Taproot?) and what derivation paths to check. This led to failed recoveries and wallet incompatibility.

Descriptors fix this by explicitly specifying everything: the script type, the keys involved (with full derivation paths), and any other parameters needed. A descriptor like wpkh([deadbeef/84h/0h/0h]xpub.../0/*) tells the wallet exactly what to look for.

Bitcoin Core migrated to descriptor wallets as the default. Many other wallets followed. Descriptors are now the standard for wallet interoperability. BIP-392 brings silent payments into that ecosystem.

What BIP-392 actually does

BIP-392 introduces three new elements to the descriptor language:

The sp() expression is a new top-level descriptor type (like wpkh() for SegWit or tr() for Taproot) specifically for silent payment outputs.
The spscan key expression uses bech32m encoding to contain the scan private key and spend public key, enabling watch-only wallets that can detect payments but not spend them. The format is spscan1q... where the q character represents silent payments version 0 (matching the sp1q address format from BIP-352).
The spspend key expression also uses bech32m encoding but contains both scan and spend private keys for full wallet functionality. The format is spspend1q... with the same versioning scheme.

Future versions can use different bech32m characters to signal compatibility.

Examples

A watch-only wallet descriptor looks like this:

sp(spscan1q...)

For a full wallet with key origin information, you would use:

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

There’s also a two-argument form for advanced setups:

sp(SCAN_KEY, SPEND_KEY)

This two-argument syntax enables interesting constructions like cold storage (scan on a hot device, spend key on a hardware wallet) or even multisig spend keys in the future.

Why new key formats?

During the December 2025 mailing list discussion, some questioned whether new key formats (spscan and spspend) were necessary. Why not just use existing extended key formats in a two-argument sp(scankey, spendkey) descriptor?

Craig Raw defended the design on several grounds:

Self-describing: The key format immediately tells you what it is. No ambiguity.

Error detection: Bech32m encoding catches typos before you make expensive mistakes.

Safety: Prevents accidentally mixing unrelated scan and spend keys from different sources.

Versioning: The q character signals version 0, leaving room for future upgrades.

The new formats stayed in the final BIP. They follow the same UX pattern as xpub display in wallet interfaces, making them familiar to users.

Who wrote this and why it matters

Craig Raw is the developer and maintainer of Sparrow Wallet, one of the most respected Bitcoin desktop wallets in the ecosystem. Sparrow is free, open-source, and focused on security, privacy, and advanced features like coin control, hardware wallet integration, and (as of early 2026) silent payment sending.

Raw has been a consistent advocate for standards and interoperability. Sparrow pioneered descriptor-based wallet management and was an early adopter of features like Payjoin and CoinJoin support. By authoring BIP-392, he’s extending that philosophy to the emerging silent payments ecosystem.

This isn’t a random developer proposing a half-baked spec. This is a maintainer with skin in the game, building infrastructure for a wallet he actively maintains. That credibility matters.

The scanning challenge

Silent payments aren’t free. The receiver has to scan the blockchain for every transaction with eligible inputs to detect payments. This is computationally expensive and requires either:

Running a full node and scanning locally (resource-intensive)
Trusting a third-party scanning service (privacy risk if you share your scan key)
Waiting for light client solutions to mature (still experimental)

BIP-392 doesn’t solve the scanning problem. But during the mailing list discussion, Craig Raw proposed optional descriptor parameters to mitigate it:

Birthday parameter: Tells the wallet which block height to start scanning from (e.g., wallet creation date). Avoids wasting cycles scanning years of irrelevant history.

Label parameters: Specifies which BIP-352 labels to scan for. Labels let you create multiple virtual addresses from one silent payment address (useful for separating income sources), but each additional label adds computational cost. Explicitly listing labels in the descriptor avoids scanning for unused ones.

These parameters may or may not be in the final merged spec (the current BIP text doesn’t include them in the formal specification), but they illustrate the kind of practical optimization that matters for real-world adoption.

What’s next

BIP-392 was merged into the Bitcoin Improvement Proposals repository on March 5, 2026. Its formal status is “Draft.” The next phase is implementation:

Likely adopters:

Sparrow Wallet (author’s project, high probability)
Bitcoin Core (if descriptor support expands)
BDK-based wallets (Bitcoin Dev Kit is descriptor-native)
Hardware wallets (for signing support)

Unknown timeline for:

Light client scanning solutions
Specialized indexing infrastructure (like Electrum servers for silent payments)
Broader wallet ecosystem adoption

The ecosystem has momentum. Silent payment support grew throughout 2025 and early 2026. BIP-392 removes a major adoption barrier by ensuring that wallets implementing silent payments won’t trap users in proprietary formats.

The boring work wins

Bitcoin privacy doesn’t need more hype. It needs infrastructure that works across wallets, survives developer exits, and doesn’t lock users into walled gardens.

BIP-392 is that infrastructure. It won’t make headlines, but it makes silent payments viable as a long-term privacy solution. By integrating with the descriptor framework, it leverages years of existing work and ensures that silent payment wallets can be as portable and interoperable as any other Bitcoin wallet.

Craig Raw’s contribution here is quiet, technical, and exactly the kind of work that makes Bitcoin better. Not flashy. Just solid.