Output Descriptor

Anna is changing the application she uses to monitor her hardware wallet. She wants to keep tracking her funds in the new application without typing recovery words into a computer. The recovery words, called a Seed Phrase, are a backup from which the wallet’s keys can be recovered. A public descriptor tells the new application which public keys to use and how to produce the same addresses. Think of it as precise instructions for constructing addresses, not another password. Software can often recognize a standard wallet’s setup by itself, but relying on guesses is not enough for an unusual configuration or Multisig (a wallet setup with several signing keys). A descriptor neither transfers money nor changes payments already received. It describes the rules a recovery must preserve. [1] [8]

A private key can create a digital signature authorizing a spend. A public key can verify that signature, but cannot create it. A public descriptor may contain an xpub: data for deriving further public keys without the ability to sign. This suits a Watch-only Wallet, which monitors payments but cannot send them by itself. Such an export still deserves privacy protection: it can link many of your addresses and their histories. Another descriptor may contain an xprv, an extended private key, or WIF, an encoding of an individual private key. That is secret material which may enable spending under the relevant conditions. Do not submit it to an online checker or store it as a harmless note. Public configuration does not replace the backups needed to sign. [1] [8]

After importing, Anna compares several receiving addresses with the original wallet. With a hardware wallet, she checks addresses on its trusted display following the manufacturer’s procedure. She also checks the change-branch configuration: the part that returns unspent money to her when paying. An identical account name is not enough. Before relying on a new backup, she verifies the complete recovery procedure for her wallet without unnecessarily exposing secret keys. If the application does not support the descriptor or shows different addresses, she first checks compatibility, network and settings. Rewriting an unfamiliar expression by guesswork is not a safe repair. [5] [8]

For a wallet requiring two signatures from three keys, two sets of recovery words and a memory that ‘it was two out of three’ are not enough. Recreating the correct spending conditions needs the public data for all three keys, their derivation rules and the exact script type. A script expresses the conditions that must be met to spend the funds. In the technical notation multi(k,...), the listed key order is used; k is the required signature count. The sortedmulti(k,...) variant sorts the derived public keys by their bytes whenever it constructs a script. These are different rules, not interchangeable names. Keep the full configuration export alongside separately protected backups of the keys needed to sign. A list of device names is not enough. [2] [8]

The # character may be followed by eight characters called a checksum, defined in BIP380. Software uses it to detect many copying errors. It is not the author’s signature, encryption or proof that the descriptor belongs to you. Someone who deliberately substitutes their own keys can also calculate a correct new checksum. Checking the text therefore belongs alongside verifying addresses and the configuration’s source. If an application reports a checksum error, first obtain the original export again; simply generating a new checksum could certify text that is already damaged. [1]

A key can be preceded by [fingerprint/path], known as key-origin information. The fingerprint is a short identifier of the starting key; the path records how the key written after it was derived. This helps a signing device locate the correct key. A further path may follow the xpub to derive individual addresses. These two parts have different jobs; they are not merely an account label. Different keys can happen to share a fingerprint, so it does not authenticate a device. A public export also cannot arbitrarily continue through Hardened Derivation, a step requiring private data; the exporting application must choose the appropriate key level. [1]

The star in /* means substituting successive numbers, such as 0, 1 and 2. Such a ranged descriptor describes more than one address; software chooses the index range to process for a particular operation. BIP389 notation <0;1> can cover two branches, commonly receiving and change, if the application supports it. But the descriptor itself does not maintain a list of used addresses or record the next unused number. Nor is the gap limit—the number of consecutive unused addresses after which a search stops—automatically part of the expression. Unused means no transaction history: an address that received funds which were later spent does not count as unused. Recovery may therefore require wallet state as well as a sufficiently broad scan range. [5] [6] [9]

A transaction output contains a scriptPubKey, the script setting the conditions for spending it later. A descriptor tells software how to construct it. The expression wpkh(KEY) describes single-key Native SegWit; KEY here is a placeholder, not a real key. Wrapping it as sh(wpkh(KEY)) changes the output format and address even though the key stays the same. Other expressions include pk(), pkh(), wsh(), addr() and raw(). They are not interchangeable choices: addr(), for instance, describes a known address but does not supply missing information needed to spend from it. This section is a configuration reference, not a requirement for beginners to write descriptors by hand. [1] [8]

A Taproot output can be spent through a key signature or through attached script conditions, if the output includes them. The notation tr(KEY) specifies an internal key without a spendable script branch; tr(KEY,TREE) adds a script tree. There is more to preserve than a list of keys. How scripts are grouped in the tree matters: changing that grouping can change their combined hash, the Merkle root, and the resulting address even if the individual conditions stay the same. Not every branch swap changes it, however. Miniscript helps describe and analyze conditions, while multi_a expresses multiple signatures in Tapscript, Taproot’s scripting language. Neither replaces a complete configuration export. [3] [8]

RPC is an interface for giving the software commands from another program or the command line. In Bitcoin Core 29, the getdescriptorinfo RPC command analyzes a descriptor. It returns a public form without private keys, plus checksum, isrange, issolvable and hasprivatekeys. The last field says whether the input contained a private key; issolvable does not mean you possess the secret keys needed to sign. Use deriveaddresses to compare derived addresses. When importing, importdescriptors also takes timestamp, active, internal, range and next_index: the starting time for finding history, whether the configuration is active, whether it handles internal change, the range and the next address index. A rescan searches the blockchain for transactions again. A timestamp set too late can miss older payments; changing the descriptor alone neither moves nor erases them. A new wallet backup is needed after import. These commands belong in your own trusted installation, not someone else’s web form. [5] [7] [8]