This guide explains BIP 392 Silent Payment Output Script Descriptors in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.
TL;DR
- What it is: BIP 392 is a Draft specification for representing BIP 352 Silent Payment wallets as output script descriptors. The new top-level sp() expression combines Silent Payment key material with sender input public keys to describe BIP341 taproot outputs.
- Why it matters: BIP 392 can make Silent Payment wallets portable within descriptor infrastructure, provided every backup clearly declares whether it is watch-only or spend-capable and implementations strictly validate keys, networks and derivation context.
- Current position: BIP 392 is a Draft specification for representing BIP 352 Silent Payment wallets as output script descriptors.
BIP 392 Silent Payment Output Script Descriptors in simple English
BIP 392 Silent Payment Output Script Descriptors: sp() is a top-level descriptor only. It creates taproot output scripts dynamically from sender inputs, so it cannot be nested under sh(), wsh() or another script wrapper.
Simple example
A node operator is checking BIP 392 Silent Payment Output Script Descriptors. A Silent Payment descriptor may expose scan capability, spending capability or both. Backups must label that authority explicitly and retain any derivation and maximum-label information required for complete scanning.
Key terms in plain English
- BIP:
- Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
- Taproot:
- A Bitcoin upgrade that added new signature and script options for spending outputs.
- Node:
- A computer running Bitcoin software that checks data and communicates with other peers.
Descriptor scope
sp() is a top-level descriptor only. It creates taproot output scripts dynamically from sender inputs, so it cannot be nested under sh(), wsh() or another script wrapper.
spscan
The Bech32m spscan form contains the private scan key and compressed public spend key. It supports detection and watch-only operation but should not grant spending authority.
spspend
The Bech32m spspend form contains both scan and spend private keys. Treat it as full-wallet secret material with encryption, access control and offline backup.
Two-argument form
sp(scan,spend) requires a private scan key and permits a single public or private spend expression, including compatible aggregate keys. Uncompressed keys are forbidden.
Origins and networks
Optional key-origin data records fingerprint and derivation depth. Mainnet and test networks use distinct human-readable prefixes; reject cross-network or bad-checksum material.
Recovery boundary
A Silent Payment descriptor may expose scan capability, spending capability or both. Backups must label that authority explicitly and retain any derivation and maximum-label information required for complete scanning.
How specialists test it
Developers test the proposal with made-up data on an isolated test network. They check normal cases and deliberately invalid cases. Different implementations should reach the same result before anyone relies on the proposal.
Frequently asked questions
What is the main point of BIP 392 Silent Payment Output Script Descriptors?
BIP 392 Silent Payment Output Script Descriptors: sp() is a top-level descriptor only. It creates taproot output scripts dynamically from sender inputs, so it cannot be nested under sh(), wsh() or another script wrapper.
For BIP 392 Silent Payment Output Script Descriptors, what should a beginner know about descriptor scope?
sp() is a top-level descriptor only. It creates taproot output scripts dynamically from sender inputs, so it cannot be nested under sh(), wsh() or another script wrapper.
For BIP 392 Silent Payment Output Script Descriptors, what should a beginner know about spscan?
The Bech32m spscan form contains the private scan key and compressed public spend key.
For BIP 392 Silent Payment Output Script Descriptors, what should a beginner know about spspend?
The Bech32m spspend form contains both scan and spend private keys. Treat it as full-wallet secret material with encryption, access control and offline backup.
Conclusion
BIP 392 can make Silent Payment wallets portable within descriptor infrastructure, provided every backup clearly declares whether it is watch-only or spend-capable and implementations strictly validate keys, networks and derivation context.
Primary sources
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
Join the ASIC Mining Discussion
Members can read and join the discussion
Log in to read comments from other miners. Create a free account if you would like to ask a question or share your experience.
Membership helps us protect the discussion from spam and keep answers useful.