Solo Mining Calculator: Estimate Odds and Timeframes
Use a solo mining calculator correctly: enter productive hashrate, network conditions, uptime and time horizon, then read expected time and probability without.
Read article
ASIC mining knowledge centre
BIP 390 musig() Descriptor Key Expression: Draft Guide
BIP 390 guide to the Draft musig() descriptor key expression, allowed Taproot contexts, derivation, KeySort, aggregate child keys and compatibility.
This guide explains BIP 390 musig() Descriptor Key Expression 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 390 is a Draft informational specification for expressing a MuSig2 aggregate public key inside output script descriptors. The musig() expression accepts several descriptor keys, applies their child derivation, sorts the resulting public keys with KeySort and aggregates them using BIP 327.
- Why it matters: BIP 390 can give MuSig2 wallets a concise, reproducible policy description. Until the Draft stabilises, deployments should pin the grammar, preserve complete descriptors and verify derived Taproot outputs across independent implementations.
- Current position: BIP 390 is a Draft informational specification for expressing a MuSig2 aggregate public key inside output script 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.
- 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.
Status
BIP 390 is Draft, Informational, version 0.2.0. Wallet exports must retain a version and should not imply that every descriptor implementation accepts the expression.
Allowed contexts
musig() can be used as a key expression inside tr(), rawtr() or sp(). It cannot be nested inside another musig() expression.
Derive then sort
Each participant key performs its specified derivation first. The derived keys are then ordered with KeySort before aggregation, so sorting original xpub strings is incorrect.
Per-index aggregation
When participant expressions contain a wildcard, a new aggregate key is computed for every child index. All devices must derive the same branch and index.
Aggregate derivation form
A path following musig() derives from the synthetic aggregate xpub described by BIP 328. Participant keys must be xpub-based and cannot also contain wildcard or multipath derivation.
No hardened aggregate path
Because no aggregate private key exists, derivation after musig() is unhardened only. Reject hardened markers anywhere in that aggregate path.
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 BIP 390 musig() Descriptor Key Expression?
BIP 390 is a Draft informational specification for expressing a MuSig2 aggregate public key inside output script descriptors. The musig() expression accepts several descriptor keys, applies their child derivation, sorts the resulting public keys with KeySort and aggregates them using BIP 327.
Is BIP 390 musig() Descriptor Key Expression active or supported today?
BIP 390 is a Draft informational specification for expressing a MuSig2 aggregate public key inside output script descriptors.
Why does BIP 390 musig() Descriptor Key Expression matter?
BIP 390 can give MuSig2 wallets a concise, reproducible policy description. Until the Draft stabilises, deployments should pin the grammar, preserve complete descriptors and verify derived Taproot outputs across independent implementations.
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 390 can give MuSig2 wallets a concise, reproducible policy description. Until the Draft stabilises, deployments should pin the grammar, preserve complete descriptors and verify derived Taproot outputs across independent implementations.
Primary sources
- BIP 390 musig() Descriptor Key Expression
- BIP 380 Output Script Descriptors
- BIP 328 MuSig2 Aggregate-Key Derivation
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
On this page
Search More Guides
BIP-110 Explained: Rules, Signalling and Why It Closed
BIP-110 explained in detail: its seven consensus restrictions, 55% signalling threshold, chain-split risk and August 2026 closure.
Read article
Bitcoin Core 29.4 Release: Chainstate Disk I/O Guide
Bitcoin Core 29.4 guide covering repeated chainstate rewrites, regular compaction, LevelDB seek compaction, transaction-data lifetime and wallet sizing fixes.
Read article
Need Advice for Your Mining Setup?
Use our guidance to build your shortlist, then speak to our team when you want help comparing hardware, power, hosting or repairs.