Skip to main content
£0.00 0

Basket

No products in the basket.

ASIC mining articles and advice

BIP 383 Multisig Output Script Descriptors Guide

BIP 383 guide covering Deployed multi() and sortedmulti(), threshold and context rules, deterministic ordering, ranged keys, script limits, recovery and vectors.

BIP 383 multisig descriptors guide cover

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.

BIP 383 multisig descriptors technical diagram
Ordering: the fields, validation boundary and operational evidence that implementations need to agree.

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.

ASIC MINER PICKS

Recommended ASIC Mining Hardware

Compare three of our highest ranked ASIC miners currently available, with live product details and pricing.
Browse all ASIC miners
MORE MINING ADVICE

More ASIC Mining Articles

Read practical advice about choosing hardware, calculating electricity costs, setting up miners, hosting and maintenance.
MINER COMMUNITY

Join the ASIC Mining Discussion

Ask a question or share what has worked for you. Your experience may help another miner make a better decision.

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.

Log in to read comments Register to join the discussion

Membership helps us protect the discussion from spam and keep answers useful.

ASIC MINING SUPPORT

Need Help Choosing an ASIC Miner?

Tell us what you want to mine, your electricity cost and where the machine will run. We can help you compare hardware, power requirements, hosting and repairs.
Contact our mining team
Browse ASIC miners