Output Descriptor

What Is an Output Descriptor?

An output descriptor (formally called an output script descriptor) is a compact, standardized string that tells wallet software exactly how to derive a set of Bitcoin addresses. It encodes the script type (such as native SegWit or Taproot), the extended public key, the master key fingerprint, and the full derivation path: everything a wallet needs to reconstruct the same addresses and monitor for incoming funds.

Descriptors were introduced by Andrew Chow in 2018 and formalized across BIPs 380 through 386. They replaced the ad-hoc approach where wallets had to guess which address types and derivation paths a user intended. Before descriptors, restoring a wallet from a seed phrase required the new software to try multiple derivation paths and script types, hoping to find the right combination. Descriptors eliminate this guesswork by making the derivation recipe explicit.

Since Bitcoin Core version 0.21, descriptor wallets have been available as the recommended wallet type, and as of version 23, they became the default for newly created wallets. Desktop wallets like Sparrow also support importing and exporting descriptors natively.

How It Works

A descriptor is a function-like expression that wraps key information in a script type. The general structure is:

script_type([fingerprint/derivation/path]xpub/child_path)

Each part serves a specific role:

• Script type: the function name (such as wpkh, tr, or multi) tells the wallet what kind of output script to produce
• Key origin: the bracketed section [fingerprint/path] records which master key was used and the derivation steps from that master to the extended key that follows
• Extended key: the xpub (or xprv for private descriptors) from which child keys are derived
• Child path: /0/* means "derive all unhardened child keys under index 0," which is the standard pattern for receiving addresses

Descriptor Syntax Examples

Here are the most common descriptor formats, each corresponding to a different address type:

# Native SegWit (P2WPKH) - BIP 84 addresses starting with bc1q
wpkh([d34db33f/84'/0'/0']xpub6ERApfZw.../0/*)

# Taproot (P2TR) - BIP 86 addresses starting with bc1p
tr([d34db33f/86'/0'/0']xpub6ERApfZw.../0/*)

# 2-of-3 Multisig in P2WSH
wsh(multi(2,
  [aaaa0001/48'/0'/0'/2']xpubA.../0/*,
  [bbbb0002/48'/0'/0'/2']xpubB.../0/*,
  [cccc0003/48'/0'/0'/2']xpubC.../0/*
))

# Sorted multisig (key order is normalized)
wsh(sortedmulti(2,
  [aaaa0001/48'/0'/0'/2']xpubA.../0/*,
  [bbbb0002/48'/0'/0'/2']xpubB.../0/*
))

The fingerprint (like d34db33f) is the first four bytes of the Hash160 of the master public key. It serves as a compact identifier so software can determine which signing device or seed produced a given key without exposing private data.

Checksums

Descriptors support an optional 8-character checksum appended after a # symbol. This checksum detects typos and copy-paste errors: up to 4 character-level mistakes are guaranteed to be caught in descriptors under 501 characters. For example:

wpkh([d34db33f/84'/0'/0']xpub6ERApfZw.../0/*)#abc12def

Bitcoin Core's getdescriptorinfo RPC can compute the checksum for any descriptor.

Multipath Descriptors (BIP 389)

Wallets typically need two descriptors: one for receiving addresses (child index 0) and one for change addresses (child index 1). BIP 389 introduced multipath expressions that combine both into a single string using the /<0;1> syntax:

wpkh([d34db33f/84'/0'/0']xpub6ERApfZw.../<0;1>/*)

Parsers expand this into two descriptors: one with /0/* for receiving and one with /1/* for change. This reduces backup complexity by halving the number of strings a user needs to store.

Why Descriptors Are Better Than Seed Phrases Alone

A seed phrase encodes the master secret, but it says nothing about how that secret was used. Two wallets can share the same seed phrase yet produce entirely different addresses depending on the script type and derivation path. This creates a serious recovery problem.

Consider a wallet using BIP 84 native SegWit addresses. If you import that seed into software that defaults to BIP 44 legacy addresses, it will derive a completely different set of keys. Your funds appear to vanish, even though they still exist on-chain. Experienced users may know to try multiple derivation paths, but this is fragile and error-prone.

Descriptors solve this by capturing the full recipe. A descriptor backup includes:

• The exact script type (P2WPKH, P2TR, P2WSH, etc.)
• The complete derivation path from master to the extended key
• The master key fingerprint for device identification
• The xpub or xprv itself
• The child derivation range for generating addresses

Any compliant wallet software can take this string and reproduce the exact same set of addresses without guessing. For a deeper look at how address types interact with derivation paths, see the guide to Bitcoin address types.

Use Cases

Wallet Backup and Recovery

The primary use case for descriptors is unambiguous wallet restoration. Instead of writing down a seed phrase plus separate notes about which wallet software, script type, and derivation path you used, you back up the descriptor string. Any descriptor-aware wallet can import it and immediately derive the correct addresses.

This is especially important as Bitcoin continues to add new address types. With Taproot, SegWit, and legacy formats all coexisting, seed-only backups become increasingly ambiguous. Descriptors future-proof wallet recovery by encoding the script type explicitly.

Multisig Coordination

Multisig wallets present the hardest coordination problem that descriptors solve. In a 2-of-3 multisig setup, each cosigner may use different hardware or software. Every participant needs the same descriptor to generate matching addresses, and recovering the wallet requires at least two seed phrases plus the descriptor that defines how they combine.

Without a shared descriptor, cosigners must manually agree on derivation paths, key ordering, and script wrapping. Descriptors make this coordination explicit and portable: one string that every participant imports into their own software. For a full exploration of multisig architecture, see the multisig wallets deep dive.

Watch-Only Wallets

Descriptors containing only xpubs (no private keys) let you create watch-only wallets that track balances and generate receiving addresses without the ability to spend. This is common for accounting systems, portfolio dashboards, and cold storage setups where the spending keys remain on an air-gapped device.

Miniscript Integration

Miniscript extends descriptors with a structured language for expressing complex spending conditions. Instead of writing raw Bitcoin Script, developers describe spending policies in a high-level format that compiles down to optimal scripts. Combined with descriptors, miniscript enables wallets to handle advanced spending conditions such as timelocked recovery paths, threshold signatures, and multi-party escrow: all described in a single importable string. See the miniscript spending policies guide for details.

BIP Specifications

Output descriptors are defined across several Bitcoin Improvement Proposals:

BIPs 380 through 385 were implemented in Bitcoin Core v0.17.0. BIP 386 for Taproot descriptors arrived in Bitcoin Core v22.0.

Risks and Considerations

Descriptor Loss Is Wallet Loss

For single-signature wallets, losing a descriptor is recoverable: you can try known derivation paths until the correct one is found. For multisig wallets, losing the descriptor can mean permanent loss of funds. Even with all the required seed phrases, you cannot reconstruct the multisig addresses without knowing the exact combination of xpubs, key ordering, threshold, and script type that the descriptor defines. Backing up the descriptor is as important as backing up the seed phrases themselves.

Privacy Implications

A descriptor containing an xpub reveals all current and future addresses derived from it. Anyone with access to the descriptor string can monitor the wallet's entire transaction history and balance. Descriptors should be stored with the same security as extended public keys: encrypted, access-controlled, and never shared publicly.

Software Compatibility

While descriptor support has become widespread in major wallet software, not all wallets implement every descriptor function. Taproot descriptors (tr()) and miniscript expressions require relatively recent software versions. Before relying on a descriptor for backup, verify that your recovery software supports the specific descriptor functions you use. The PSBT standard complements descriptors by providing a portable format for partially signed transactions, and wallets that support both tend to offer the most robust interoperability.

Hardened Derivation and Xpub Limits

Descriptors with hardened derivation steps above the xpub require the private key for those steps. An xpub-only descriptor cannot derive child keys past a hardened boundary. This means watch-only descriptors are limited to unhardened child paths below the exported xpub, which is the standard approach for HD wallet architectures following BIP 44, 84, or 86.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.