This guide explains BIP 383 multisig 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 383 specifies the deployed multi() and sortedmulti() descriptor expressions for threshold multisignature scripts. Both take a threshold and one or more key expressions; multi() preserves the supplied key order, while sortedmulti() sorts derived public keys lexicographically when producing each script.
- Why it matters: BIP 383 makes threshold multisig scripts reproducible through explicit descriptor policy. Recovery depends on the exact wrapper, threshold, key origins, ordering rule and range state, all of which must be verified before funds arrive.
- Current position: BIP 383 is Deployed and Informational and requires BIP 380.
BIP 383 multisig descriptors in simple English
BIP 383 multisig descriptors: Store the complete checksummed descriptor with threshold, all keys, origins, branches and script wrapper. One seed or an unordered cosigner list is not a multisig backup.
Simple example
A node operator is checking BIP 383 multisig descriptors. When extended keys are ranged, every key uses the same child index for one derived script.
Key terms in plain English
- BIP:
- Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
- Consensus:
- The shared rules full nodes use to decide whether blocks and transactions are valid.
- Node:
- A computer running Bitcoin software that checks data and communicates with other peers.
Status and expressions
BIP 383 is Deployed and Informational and requires BIP 380. The grammar is multi(k, keys) or sortedmulti(k, keys), with k no greater than the number of keys.
Contexts
The expressions may be top level or inside sh() or wsh(). Outer context determines P2SH, P2WSH or nested construction and can impose compressed-key and script-size limits.
Ordering
multi() uses descriptor order. Sortedmulti() derives keys for the child index first, then sorts the resulting public keys lexicographically, making script order deterministic across cosigners.
Ranged keys
When extended keys are ranged, every key uses the same child index for one derived script. Coordinate branches and indexes so participants reconstruct identical receive and change policies.
Limits
Reject non-numeric, zero or excessive thresholds, more keys than the script context permits, forbidden key forms and derived scripts exceeding consensus or standardness limits.
Recovery
Store the complete checksummed descriptor with threshold, all keys, origins, branches and script wrapper. One seed or an unordered cosigner list is not a multisig backup.
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 383 multisig descriptors?
BIP 383 multisig descriptors: Store the complete checksummed descriptor with threshold, all keys, origins, branches and script wrapper.
For BIP 383 multisig descriptors, what should a beginner know about status and expressions?
BIP 383 is Deployed and Informational and requires BIP 380. The grammar is multi(k, keys) or sortedmulti(k, keys), with k no greater than the number of keys.
For BIP 383 multisig descriptors, what should a beginner know about contexts?
The expressions may be top level or inside sh() or wsh(). Outer context determines P2SH, P2WSH or nested construction and can impose compressed-key and script-size limits.
For BIP 383 multisig descriptors, what should a beginner know about ordering?
multi() uses descriptor order. Sortedmulti() derives keys for the child index first, then sorts the resulting public keys lexicographically, making script order deterministic across cosigners.
Conclusion
BIP 383 makes threshold multisig scripts reproducible through explicit descriptor policy. Recovery depends on the exact wrapper, threshold, key origins, ordering rule and range state, all of which must be verified before funds arrive.
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.