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.
BIP 393 Output Script Descriptor Annotations in simple English
BIP 393 Output Script Descriptor Annotations: Annotations follow the script after one question mark, use ampersands between key-value pairs and precede the checksum.
Simple example
A node operator is checking BIP 393 Output Script Descriptor Annotations. The checksum covers the full literal string, including pair order. Test annotated and stripped forms to ensure script sets are identical.
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 the main point of BIP 393 Output Script Descriptor Annotations?
BIP 393 Output Script Descriptor Annotations: Annotations follow the script after one question mark, use ampersands between key-value pairs and precede the checksum.
For BIP 393 Output Script Descriptor Annotations, what should a beginner know about general form?
Annotations follow the script after one question mark, use ampersands between key-value pairs and precede the checksum.
For BIP 393 Output Script Descriptor Annotations, what should a beginner know about grammar?
Keys contain lowercase ASCII letters and occur at most once. Values are non-negative decimal integers with no leading zero except zero itself.
For BIP 393 Output Script Descriptor Annotations, what should a beginner know about 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.
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.
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.