This guide explains BIP 393 Output Script Descriptor Annotations 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 393 is a Draft specification for optional key-value annotations appended to BIP 380 output descriptors. Metadata such as birth height, gap limit and Silent Payment maximum label can travel with a backup without changing the scripts the descriptor generates.
- Why it matters: BIP 393 binds practical scanning parameters to descriptor backups without changing their scripts. It improves recovery only when parsers validate strictly, wallets update increasing bounds and operators retain the checksum-protected original.
- Current position: BIP 393 is a Draft specification for optional key-value annotations appended to BIP 380 output descriptors.
What this means in simple English
A BIP is a document that proposes or explains a Bitcoin idea, standard or rule. A BIP number does not mean the idea is active. Some BIPs are widely used, while others are drafts or historical proposals.
You do not need to read code to understand the main point. Start with the status, the problem being addressed and the practical effect on ordinary users, wallets, miners or node operators.
Simple example
Think of a mempool as one node’s waiting room for valid transactions that have not yet entered a block. Different nodes can have different waiting rooms, and the contents can change from one second to the next.
Key terms in plain English
- BIP
- Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
- Node
- A computer running Bitcoin software that checks data and communicates with other peers.
General form
Annotations follow the script after one question mark, use ampersands between key-value pairs and precede the checksum. The checksum covers the full literal string, including pair order.
Grammar
Keys contain lowercase ASCII letters and occur at most once. Values are non-negative decimal integers with no leading zero except zero itself. Empty, negative, duplicate or malformed pairs are invalid.
Defined keys
bh is the earliest scan block height, gl the consecutive-unused address gap limit and ml the highest Silent Payment label index required for recovery.
Lower bounds
Values record minimum work needed to recover all funds at export time. Later exports may increase them as wallet use expands, but must not reduce them without an evidence-backed reason.
Unknown keys
A supporting implementation must ignore unknown annotations rather than reject the descriptor. It must still retain the checksum-protected literal backup and avoid assigning invented semantics.
Script invariance
Annotations provide operational metadata only and do not alter generated scripts or addresses. Test annotated and stripped forms to ensure script sets are identical.
Compatibility
Plain descriptors remain valid. A legacy parser may require annotations to be stripped and the checksum recomputed; preserve the annotated original so recovery bounds are not discarded. Build a revision-pinned evidence pack on an isolated node, wallet or protocol harness.
Frequently asked questions
What is BIP 393 Output Script Descriptor Annotations?
BIP 393 is a Draft specification for optional key-value annotations appended to BIP 380 output descriptors. Metadata such as birth height, gap limit and Silent Payment maximum label can travel with a backup without changing the scripts the descriptor generates.
Is BIP 393 Output Script Descriptor Annotations active or supported today?
BIP 393 is a Draft specification for optional key-value annotations appended to BIP 380 output descriptors.
Why does BIP 393 Output Script Descriptor Annotations matter?
BIP 393 binds practical scanning parameters to descriptor backups without changing their scripts. It improves recovery only when parsers validate strictly, wallets update increasing bounds and operators retain the checksum-protected original.
Do beginners need to use the technical details?
No. Most readers only need to understand the idea and its current status. Developers and node operators can use the primary sources when they need the exact technical rules.
Conclusion
BIP 393 binds practical scanning parameters to descriptor backups without changing their scripts. It improves recovery only when parsers validate strictly, wallets update increasing bounds and operators retain the checksum-protected original.
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.
