A Bitcoin recovery plan can preserve every signing device’s seed backup and still leave an important question unanswered: how were those keys combined into the wallet? Output descriptors record that configuration. They can help replacement software reconstruct the intended addresses and spending conditions instead of guessing from the keys alone. This is the recovery problem identified in BIP 380.
For a multisignature wallet, preserving the configuration deserves attention alongside preserving the signing secrets. A useful review starts before a device fails, while the original wallet is available for comparison.
What a descriptor describes
An output descriptor is a structured description of Bitcoin output scripts. It can specify the script type, keys and derivation paths used to generate addresses. Those paths identify branches within a hierarchical wallet’s key tree. Key-origin information can also include a fingerprint identifying a master key and the path leading to an exported key. BIP 380’s descriptor structure
This matters because the same underlying keys can participate in different wallet constructions. A seed backup does not, by itself, reliably tell replacement software which construction the owner used. BIP 380 explicitly identifies missing script-type and derivation-path information as sources of recovery incompatibility. Recovery motivation
A descriptor captures technical configuration. Its usefulness depends on keeping the correct export and using software that supports its contents.
Two signatures can still require three public keys
Consider an illustrative two-of-three multisignature wallet. Any two of its three signing keys can satisfy the threshold. Reconstructing the wallet’s scripts, however, requires the public-key information for all three participants, together with the threshold and script construction. BIP 383 defines its multisig expressions using the required signature count and the complete list of participating key expressions. BIP 383
The recovery consequence follows from that structure: two surviving seed backups do not automatically supply the missing participant’s public-key information. A preserved configuration containing all three extended public keys can supply that information without requiring the third signing secret. This distinction is easy to overlook when “two of three” becomes the entire backup plan.
Key handling also matters. BIP 383’s multi expression preserves the specified public-key order. Its sortedmulti expression sorts the derived public keys before constructing the script. These rules should survive recovery exactly as configured; rearranging an unsorted key list can change the wallet’s addresses. Ordering rules
COLDCARD’s documentation reinforces the practical point by warning owners of unsorted multisig wallets to preserve their descriptors and key order. COLDCARD’s unsorted-multisig guidance
Watch only access reveals financial activity
An extended public key, commonly called an xpub, can derive non-hardened descendant public keys without providing the corresponding signing secrets. BIP 32 describes sharing account-level public information so an auditor can inspect transactions without receiving private keys. BIP 32’s derivation and audit model
A complete public descriptor can therefore let compatible software reconstruct and monitor the outputs it describes. The visibility can extend to future addresses in those derivation branches, rather than only the address currently displayed. Its scope depends on the keys, paths and script information supplied; an account export does not automatically reveal every account derived from the same seed. BIP 32’s selective-sharing model
Treat that monitoring capability as private financial information. COLDCARD expressly marks its watch-only multisig export as privacy-sensitive because it includes every participant’s xpub. Avoid pasting real descriptors into public support posts, online converters or screenshots. Export privacy warning
A descriptor can contain private keys
The word “descriptor” does not establish that a file is watch-only. Bitcoin Core’s descriptor language also accepts private keys, including extended private keys called xprvs and keys in Wallet Import Format. A descriptor containing them requires the protections appropriate to signing secrets. Bitcoin Core’s private-key support
Export options deserve a careful reading. Bitcoin Core’s version 30 documentation shows that listdescriptors defaults to public output but offers an option to show private descriptors. That is a product-specific behavior, not a promise about every wallet’s export button. Bitcoin Core’s export option
Before copying or sharing an export, establish which kind it contains through the wallet’s documentation. A filename or a familiar-looking prefix somewhere in a long string is insufficient reassurance.
Preserve a usable recovery record
Keep the wallet’s supported configuration export intact, including the script type, threshold, every cosigner’s public-key information, derivation paths and ordering rule. Preserve receive and change coverage. Bitcoin Core’s export documentation distinguishes receiving from change descriptors and includes metadata such as creation time, derivation range and the next address index. Descriptor export fields
Use the wallet’s documented verification process to compare reconstructed addresses with the existing wallet before relying on the backup. COLDCARD specifically advises cross-checking multisig addresses against the coordinator. Matching addresses checks configuration; it does not prove that all required signing secrets are recoverable. Address verification guidance
Retain the descriptor checksum too. It helps detect copying errors, but it neither encrypts the contents nor proves that the descriptor belongs to the intended wallet. Bitcoin Core documents it as protection against typing and copy-paste mistakes. Checksum purpose
The goal is a recovery record someone can verify: the intended wallet configuration remains available, its privacy is protected, and the required signing backups remain usable.