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.
BIP 390 musig() Descriptor Key Expression: 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.
A node operator is checking BIP 390 musig() Descriptor Key Expression. The derived keys are then ordered with KeySort before aggregation, so sorting original xpub strings is incorrect.
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.
musig() can be used as a key expression inside tr(), rawtr() or sp(). It cannot be nested inside another musig() expression.
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.
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.
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.
Because no aggregate private key exists, derivation after musig() is unhardened only. Reject hardened markers anywhere in that aggregate path.
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.
BIP 390 musig() Descriptor Key Expression: BIP 390 is Draft, Informational, version 0.2.0.
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.
musig() can be used as a key expression inside tr(), rawtr() or sp().
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.
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.
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
BIP 450 guide to Draft Formosa themed mnemonic stories, entropy and checksum mapping, theme JSON, BIP39 conversion, passphrases and recovery safety.
BIP 393 guide to Draft descriptor annotations for birth height, gap limit and Silent Payment max label, checksum rules, parsing and recovery safety.
BIP 392 guide to Draft sp() descriptors, spscan and spspend encodings, watch-only and full-wallet forms, key origins, recovery and validation.
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.