Output Descriptor

An output descriptor is a compact, machine-readable string that fully and unambiguously describes how a set of Bitcoin outputs can be spent. Defined in BIP380 and the related BIP381-386, descriptors solve a real interoperability problem: the same xpub can legitimately produce legacy, wrapped-SegWit, or native-SegWit addresses, and a bare xpub does not say which. Wallets that guessed wrong showed users incorrect addresses and empty balances. Descriptors end that guessing by writing down, in one line, everything a wallet needs to reconstruct your addresses exactly.

What a descriptor contains

A descriptor wraps the key material in an explicit script expression that names the output type, plus a key expression that states the master-key fingerprint and the exact derivation path. For example, wpkh([d34db33f/84'/0'/0']xpub.../0/*) tells any compliant wallet three things with no ambiguity: build native SegWit P2WPKH outputs, the keys come from the master with that fingerprint via path m/84'/0'/0', and addresses run along the external chain. A trailing checksum guards against transcription errors. The script-expression vocabulary covers the whole landscape: pkh() for legacy, sh(wpkh()) for wrapped SegWit, wpkh() for native SegWit, tr() for Taproot, and wsh(multi(...)) or sortedmulti() for multisig policies, where every cosigner's fingerprint, path, and xpub is spelled out explicitly.

Why multisig makes descriptors non-optional

For a single-signature wallet, a seed plus a known standard path usually suffices to recover. Multisig is far less forgiving: recovering a 2-of-3 requires knowing every cosigner's xpub (not just the two seeds you are signing with), the exact script template, key ordering or sorting rules, and each derivation path. Miss any one detail and the addresses simply do not match. A descriptor captures all of it in a single string, which is why serious multisig practice treats the descriptor (or its wallet-file equivalent) as a first-class backup artifact alongside the seeds — store it with each key, since it contains no spending power by itself, only the map.

Descriptors in practice

Modern Bitcoin Core wallets are descriptor-based by default, and the wider ecosystem — hardware-wallet coordinators, watch-only tools, multisig platforms — speaks descriptors as the common interchange format. Backing up the descriptor alongside your seed means a future recovery tool can rebuild your wallet precisely, without trial-and-error over script types or fighting the gap limit with blind rescans. Related BIPs extend the language with miniscript, letting complex spending policies (timelocks, fallback keys) be written in the same analyzable form. For a sovereign holder the discipline is simple: if you cannot produce the descriptor for a wallet, you do not fully understand how to recover it.

The checksum deserves a closer look, because it shows the design's care for humans. Every descriptor can carry an eight-character suffix after a #, computed so that common transcription mistakes — a swapped pair of characters, a mistyped letter — are caught before a wallet acts on bad data. Bitcoin Core will compute the checksum for any descriptor you give it, which doubles as a quick validity test when assembling one by hand. Exporting is equally practical: most modern wallet software will show or dump its descriptors on request, and copying that string into your backup documentation takes a minute. It is the cheapest insurance in Bitcoin — a single line of text that converts a future recovery from forensic archaeology into a paste operation. Test it once by importing the descriptor into a fresh watch-only setup and confirming the first few addresses match your live wallet exactly.

Descriptors are the modern, unambiguous successor to passing around a raw extended public key (xpub), they power robust watch-only wallets, and they build directly on the BIP32 HD wallet derivation model. See descriptor wallet for the wallet architecture built around them.