If you’ve ever looked at advanced Bitcoin wallet software, you may have encountered a strange-looking string such as wpkh(...), tr(...), or wsh(multi(...)).
At first glance, these strings can look like programming code.
They are actually something much more useful.
They are called Bitcoin output descriptors.
An output descriptor is a standardized way of describing the Bitcoin scripts, keys, and derivation information that a wallet uses to identify and create the outputs it controls. Bitcoin Improvement Proposal (BIP) 380 defines the general descriptor language, while additional BIPs define specific descriptor types for SegWit, multisig, Taproot, and other Bitcoin script constructions.
For beginners, the easiest way to think about a descriptor is as a blueprint for a Bitcoin wallet’s spending conditions and addresses.
Instead of simply saying:
“This wallet belongs to these keys.”
a descriptor can describe:
“This wallet uses these keys, this derivation path, and this type of Bitcoin script to determine which outputs belong to it.”
That distinction becomes extremely important when backing up, restoring, importing, or creating watch-only Bitcoin wallets.
What Is a Bitcoin Output Descriptor?
A Bitcoin output descriptor is a structured expression that describes a collection of Bitcoin output scripts.
In simpler terms, it tells wallet software what kinds of Bitcoin outputs it should recognize as belonging to a particular wallet and how those outputs should be constructed.
Bitcoin Core documentation describes descriptors as a language for describing collections of output scripts. Bitcoin Core’s wallet code uses descriptors internally to reason about which outputs belong to a wallet.
A descriptor can describe things such as:
- A public key
- A public-key hash
- A SegWit output
- A multisig arrangement
- A Taproot output
- An extended public key
- Key derivation paths
- A specific Bitcoin address
- A raw Bitcoin script
This gives wallet software much more information than simply storing a list of addresses.
Why Were Output Descriptors Created?
To understand why descriptors matter, we first need to look at an older problem with Bitcoin wallet backups.
Traditionally, a wallet backup might focus primarily on its private keys or seed phrase.
That can be enough to recover the keys, but knowing the keys alone doesn’t necessarily tell recovery software everything about how the wallet was constructed.
For example, Bitcoin has several different output types.
A wallet might use:
Legacy P2PKH
or:
SegWit P2WPKH
or:
Nested SegWit P2SH-P2WPKH
or:
Taproot P2TR
A wallet also needs to know how its keys are derived.
Different wallets can use different derivation paths or wallet structures.
BIP 380 was created partly to address this problem by providing a generic language that can explicitly describe both script types and key derivation information.
This makes wallet backups and exports more descriptive.
Why a Seed Phrase Isn’t Always the Whole Story
A seed phrase is extremely important.
It can be used to derive the private keys associated with a wallet.
But imagine two wallet systems start with the same underlying seed and then use different derivation paths or different output types.
They could potentially generate different sets of addresses.
That’s where descriptors become useful.
A descriptor can tell recovery software things such as:
Which keys to use
How those keys are derived
What script type should be created
Which spending conditions apply
So instead of recovering only the keys, the wallet can recover the rules for using those keys.
BIP 380 specifically notes that traditional backups based only on private keys can be insufficient for recovering the correct output scripts and addresses, particularly with newer output types and different derivation paths.
Descriptor vs. Bitcoin Address
This is one of the most important distinctions for beginners.
A Bitcoin address usually represents a particular destination for receiving Bitcoin.
A descriptor can describe a whole collection of possible output scripts and the keys or derivation rules used to generate them.
Think of it like this:
Bitcoin address = one destination
Descriptor = blueprint describing how destinations are generated or recognized
For example, a wallet may generate many receiving addresses over time.
Instead of storing every address individually, wallet software can use a descriptor that describes the underlying pattern.
This becomes especially useful for wallets that generate new addresses automatically.
A Simple Descriptor Example
Consider a simplified descriptor:
wpkh(KEY)
You don’t need to understand every character yet.
The important part is:
wpkh
This tells the software what type of output is being described.
The KEY represents the key information used by that descriptor.
wpkh() is associated with Pay-to-Witness-Public-Key-Hash, commonly known as a native SegWit P2WPKH output. BIP 382 defines SegWit descriptor expressions including wpkh() and wsh().
The descriptor is therefore more informative than a random-looking address.
It tells compatible software how the output should be constructed.
What Does pkh() Mean?
Another descriptor expression is:
pkh(KEY)
The pkh() expression represents a Pay-to-Public-Key-Hash (P2PKH) output.
P2PKH is one of Bitcoin’s older standard output types.
A descriptor using pkh() therefore tells the wallet software that the relevant key should be used to construct P2PKH outputs.
BIP 381 defines pk() and pkh() for non-SegWit output scripts.
You don’t need to memorize these expressions.
The important idea is that descriptor functions identify the type of Bitcoin output being described.
What Does wpkh() Mean?
wpkh() describes a native SegWit Pay-to-Witness-Public-Key-Hash output.
You may already know about SegWit from our guide to What Is Bitcoin SegWit?
The descriptor simply provides a standardized way of describing that output type.
For example:
wpkh(KEY)
can be read conceptually as:
“Create a native SegWit output using this key.”
The actual descriptor can be much more complicated when extended keys and derivation paths are included.
But the basic concept remains the same.
What Does tr() Mean?
Bitcoin’s Taproot upgrade introduced another major output type.
Descriptors can represent Taproot outputs using:
tr(KEY)
The tr() expression describes a Pay-to-Taproot output.
It can also represent Taproot script trees using a more advanced form of the expression.
Bitcoin Core’s current descriptor documentation lists tr() among the supported output descriptor expressions.
This is another example of why descriptors are useful.
Instead of the wallet simply knowing that it has some keys, the descriptor can explicitly describe the type of output those keys are associated with.
Descriptors Can Describe Multisig
Descriptors become even more interesting when multiple keys are involved.
Suppose you have a 2-of-3 multisig wallet.
You have three public keys:
Key A
Key B
Key C
The wallet requires any two of them to authorize a spend.
A descriptor can represent this policy using an expression such as:
multi(2,KEY_A,KEY_B,KEY_C)
A sorted version can use:
sortedmulti(2,KEY_A,KEY_B,KEY_C)
The exact descriptor used in a real wallet may contain much more information, including key origins and derivation paths.
BIP 383 defines multi() and sortedmulti() descriptor expressions for multisig scripts.
This is one reason descriptors are so valuable for advanced wallets.
They don’t merely identify individual keys.
They can describe how multiple keys work together.
Descriptors and Your Existing Multisig Article
This connects directly to our previous guide on What Is a Bitcoin Multisig Wallet?
With multisig, the wallet isn’t simply:
“Here’s my private key.”
Instead, it has a spending policy.
For example:
2 of 3 keys required
A descriptor can express that policy in a standardized form.
This makes it easier for compatible wallet software to understand how the wallet should generate addresses and recognize outputs belonging to that multisig setup.
In other words:
Multisig describes the spending rule.
The descriptor describes that rule in a standardized machine-readable form.
Descriptors and Bitcoin Script
Descriptors also connect closely with Bitcoin Script.
If you’ve read our guide to What Is Bitcoin Script?, you know that Bitcoin uses scripts to define spending conditions.
A descriptor provides a higher-level way to describe the output scripts a wallet expects.
You don’t have to manually write Bitcoin Script every time you want to describe a wallet.
Instead, expressions such as:
pkh()
wpkh()
wsh()
multi()
tr()
can describe common script structures.
Bitcoin Core supports descriptors for several output types, including P2PK, P2PKH, P2SH, P2WPKH, P2WSH, P2TR, multisig, and other constructions.
What Is an Extended Public Key?
You’ll often see extended public keys, commonly written as xpub or related extended-key formats, inside descriptor expressions.
An extended public key can be used to derive a sequence of public keys without exposing the corresponding private keys.
That makes extended public keys useful for watch-only wallets.
For example, imagine you have a hardware wallet containing your private keys.
You want your desktop computer to monitor your Bitcoin without giving the computer access to those private keys.
You can provide appropriate public information instead.
A descriptor can combine that public key information with the necessary derivation instructions and output type.
The computer can then determine which addresses belong to the wallet without needing the private keys.
This is an important distinction:
Watch-only wallet = can observe and construct relevant transaction information without possessing the private keys needed to authorize spending.
Descriptors Can Include Derivation Paths
A descriptor can also specify how keys are derived.
This is important because HD wallets don’t normally use just one key.
They derive many keys from a master secret according to a hierarchy.
For example, a descriptor may contain information resembling:
[fingerprint/84h/0h/0h]xpub.../0/*
Don’t worry if this looks complicated.
The important pieces are:
Fingerprint
Identifies the origin of the key.
Derivation path
Describes how the key was derived.
Extended public key
Provides the public information needed for further derivation.
/0/*
Can indicate a branch and a changing address index.
The exact syntax depends on the descriptor and wallet setup.
BIP 380 defines key expressions that can include key-origin information, extended public keys, and derivation paths.
Why This Matters for Wallet Recovery
Imagine you lose the computer that previously managed your Bitcoin wallet.
You still have the seed phrase.
That’s good.
But when restoring the wallet, the new software needs to know what type of addresses and derivation structure it should look for.
If the wallet’s descriptor information is available, it can provide a much more precise description of the wallet’s structure.
This can help avoid situations where a recovery tool generates addresses that don’t match the ones previously used by the wallet.
BIP 380’s motivation specifically discusses interoperability problems caused by backups that don’t preserve script type and derivation-path information.
Descriptor Checksum
You may notice that some descriptors end with something like:
#xxxxxxxx
That section is a descriptor checksum.
The checksum helps software detect errors in the descriptor string.
This matters because descriptors can become very long.
A single accidental character change could alter their meaning.
BIP 380 defines an optional eight-character alphanumeric checksum for descriptors. Applications may require a checksum when accepting descriptors.
So if you manually copy a descriptor, don’t casually modify characters or remove the checksum without understanding what you’re doing.
Are Descriptors Private?
This depends on what information the descriptor contains.
A descriptor containing only public information may not directly reveal your private keys.
For example, a watch-only descriptor can use extended public keys.
However, some descriptor formats can contain private key material.
Therefore, you should never assume that every descriptor is safe to publish or share publicly.
Treat a descriptor according to the sensitivity of the information it contains.
Most importantly:
Never share a descriptor containing private keys or other sensitive wallet information.
Are Descriptors the Same as Seed Phrases?
No.
They serve different purposes.
A seed phrase is used to recover or derive wallet keys.
A descriptor describes how keys and scripts are used to identify or construct wallet outputs.
You can think of them as two different pieces of a wallet’s recovery information.
A seed can provide the cryptographic foundation.
A descriptor can provide the instructions describing how that foundation is used.
This is why descriptor-based wallet backups can be more expressive than a seed alone.
Why Beginners Should Care About Descriptors
You might be thinking:
“This sounds like something only Bitcoin developers need to understand.”
Not necessarily.
You may never manually type a descriptor.
Your wallet software might handle everything automatically.
But understanding the concept helps explain several important Bitcoin features:
- How watch-only wallets work
- How multisig wallets are represented
- How wallets recover addresses
- How HD wallet derivation fits into wallet recovery
- How different script types are identified
- How wallet software can share wallet structure
- Why a seed phrase doesn’t always describe every wallet detail by itself
In other words, descriptors sit behind many of the advanced wallet features you may eventually encounter.
The Big Idea
Don’t let the complicated-looking strings scare you.
A Bitcoin output descriptor is essentially a blueprint that tells compatible wallet software what Bitcoin outputs belong to a wallet and how those outputs should be constructed.
It can describe:
Keys
↓
Derivation paths
↓
Script type
↓
Spending conditions
↓
Bitcoin outputs
That’s much more information than a single Bitcoin address provides.
And that’s why descriptors are particularly useful for modern Bitcoin wallets.
How to Read a Descriptor
A descriptor generally has a function followed by one or more arguments.
For example:
wpkh(KEY)
You can think of this as:
Function → Key
The function tells the wallet what type of output or spending structure is being described.
The key tells it which cryptographic key information should be used.
More complicated descriptors simply place functions inside other functions.
For example:
sh(wpkh(KEY))
Here, wpkh(KEY) describes one output structure.
Then sh(...) wraps that structure inside another output type.
This is known as nesting.
1. pkh() — Pay-to-Public-Key-Hash
The pkh() expression describes a traditional Pay-to-Public-Key-Hash (P2PKH) output.
A simple conceptual descriptor is:
pkh(KEY)
The wallet uses the supplied key to construct the corresponding P2PKH output script.
P2PKH is one of Bitcoin’s oldest commonly used output types.
You may recognize addresses associated with this output type because traditional P2PKH addresses commonly begin with:
1
For example:
1Example...
The actual address depends on the key and network.
The important point is that pkh() tells the wallet which output structure it is dealing with.
BIP 380 includes pkh() as one of the standard descriptor expressions for describing Bitcoin output scripts. (github.com)
2. wpkh() — Native SegWit
The wpkh() expression represents a native SegWit Pay-to-Witness-Public-Key-Hash (P2WPKH) output.
A simple descriptor looks like:
wpkh(KEY)
This is commonly associated with modern SegWit addresses beginning with:
bc1q
on Bitcoin mainnet.
Compared with older P2PKH outputs, native SegWit provides a more efficient transaction structure.
If you’ve already read our article What Is Bitcoin SegWit?, you can think of wpkh() as the descriptor-language representation of a common native SegWit output.
BIP 382 specifies descriptor expressions for SegWit outputs, including wpkh() and wsh(). (github.com)
3. sh() — Pay-to-Script-Hash
The sh() expression represents Pay-to-Script-Hash (P2SH).
For example:
sh(...)
The expression inside the parentheses describes the spending structure associated with the P2SH output.
One particularly important example is:
sh(wpkh(KEY))
This represents P2SH-wrapped SegWit, commonly called nested SegWit.
The outer sh() represents the P2SH layer.
The inner wpkh() represents the SegWit spending structure.
Conceptually:
P2SH
↓
P2WPKH
↓
Public key
This type of construction was useful during Bitcoin’s transition to SegWit because it allowed SegWit spending conditions to be wrapped inside a P2SH output.
4. wsh() — Pay-to-Witness-Script-Hash
Now we move into more advanced territory.
wsh() represents Pay-to-Witness-Script-Hash (P2WSH).
Unlike wpkh(), which directly describes a public-key-hash based SegWit output, wsh() can describe more complex witness scripts.
For example:
wsh(SCRIPT)
The script inside the expression determines the spending conditions.
This makes wsh() particularly useful for things such as multisig.
wsh() + Multisig
Imagine a wallet requires two signatures from three authorized keys.
Conceptually, the spending policy is:
2-of-3
A descriptor might look like:
wsh(multi(2,KEY_A,KEY_B,KEY_C))
Let’s break it apart.
wsh()
The outer function represents P2WSH.
multi()
The inner function represents a multisig policy.
2
The wallet requires two signatures.
KEY_A, KEY_B, KEY_C
These represent the three participating keys.
So the whole expression tells compatible wallet software:
Use a SegWit script-hash output containing a 2-of-3 multisig spending policy.
Real-world descriptors can be considerably longer because they may contain extended public keys, derivation paths, key-origin information, and checksums.
But the underlying idea is exactly the same.
5. multi() — Multisignature
The multi() function describes a multisignature script.
For example:
multi(2,KEY_A,KEY_B,KEY_C)
The first number represents the required number of signatures.
The remaining arguments represent the participating keys.
Therefore:
multi(2,A,B,C)
means:
2 signatures required from 3 keys.
Likewise:
multi(3,A,B,C)
means:
3 signatures required from 3 keys.
And:
multi(1,A,B,C)
means:
1 signature required from 3 keys.
The multi() expression is therefore a compact way of describing a multisig policy.
6. sortedmulti() — Multisig With Sorted Keys
You may also encounter:
sortedmulti()
It works similarly to multi(), but the keys are sorted according to the descriptor rules.
For example:
sortedmulti(2,KEY_A,KEY_B,KEY_C)
can describe a 2-of-3 multisig arrangement while ensuring the key ordering is deterministic.
Why does ordering matter?
Because Bitcoin scripts are sensitive to the ordering of keys.
If different participants construct the same multisig wallet using different key orders, they could accidentally produce different scripts.
A deterministic ordering convention helps participants produce the same result.
This becomes especially useful in collaborative multisig setups.
7. tr() — Taproot
Bitcoin’s Taproot upgrade introduced a new output type.
Descriptors represent Taproot using:
tr()
The simplest form is:
tr(KEY)
This describes a Taproot output using the supplied internal key.
Taproot can also involve a script tree, making more advanced descriptors possible.
For example, a Taproot descriptor can conceptually describe:
Internal key
Optional spending scripts
This allows Taproot to support sophisticated spending policies while keeping the descriptor representation structured.
BIP 386 defines the tr() descriptor expression for Taproot outputs. (github.com)
Why Is tr() More Complicated?
Taproot isn’t simply another version of P2PKH.
It combines key-path spending with the ability to use script paths.
A simplified Taproot output can therefore be represented as:
Key path
or potentially:
Script path
depending on how the output was constructed.
A descriptor can represent this structure.
This is one reason descriptors are valuable for modern Bitcoin wallets.
They can describe not just a single key but complex spending structures.
Extended Public Keys Inside Descriptors
Now let’s look at one of the most important pieces you’ll encounter in real-world descriptors:
Extended public keys.
You may see strings beginning with:
xpub
or other extended-key prefixes depending on the network and derivation scheme.
An extended public key allows compatible software to derive child public keys without possessing the corresponding private keys.
This is extremely useful for watch-only wallets.
Imagine your private keys remain safely inside a hardware wallet.
You want a computer to monitor your addresses.
Instead of giving the computer your private keys, you can provide suitable public information.
The computer can then derive public addresses and monitor incoming transactions.
This is one of the practical applications of descriptor-based wallets.
What Is a Watch-Only Descriptor?
A watch-only wallet can monitor Bitcoin associated with certain keys or scripts without having the private keys required to spend those coins.
For example, imagine your descriptor contains an extended public key.
The wallet software can use it to derive addresses.
When Bitcoin arrives at one of those addresses, the watch-only wallet can recognize the transaction.
However, it cannot independently authorize spending because it doesn’t possess the corresponding private keys.
This creates a useful separation:
Watching
→ Computer
Signing
→ Hardware wallet
This is closely related to the PSBT workflow discussed in our previous article.
Descriptors and PSBTs
PSBT and descriptors solve different problems, but they work well together.
Think about a hardware-wallet setup.
The descriptor tells wallet software:
“These are the keys and spending rules associated with this wallet.”
The PSBT tells the signer:
“This is the transaction that needs to be reviewed and signed.”
So you can think of them as two pieces of the same larger workflow.
Descriptor
Describes wallet structure.
PSBT
Carries transaction information through the signing workflow.
Hardware wallet
Uses its private key to sign.
Final transaction
Gets broadcast to Bitcoin.
This relationship becomes especially useful in multisig and advanced self-custody setups.
What Is a Key Origin?
Real descriptors can contain information about where a key came from.
You might see something resembling:
[f23a9b12/84h/0h/0h]xpub...
The part inside the square brackets is called key-origin information.
It can include:
- Key fingerprint
- Derivation path
For example:
[f23a9b12/84h/0h/0h]
The fingerprint identifies the master key from which the extended key originated.
The derivation path describes the route used to derive the relevant extended key.
This information helps wallets understand how a particular key fits into the overall HD wallet structure.
BIP 380 defines key-origin information as part of descriptor key expressions. (github.com)
Understanding Derivation Paths
If you’ve read our article about HD Wallets, you already know that one master seed can generate a hierarchy of keys.
A derivation path describes a route through that hierarchy.
For example:
m/84'/0'/0'
can represent a particular branch of an HD wallet.
A descriptor can contain derivation information so wallet software knows how to derive the relevant keys.
You may also see wildcards such as:
/0/*
The * can represent a changing child index.
For example:
/0/0
could represent one receiving address.
/0/1
could represent the next.
/0/2
could represent another.
The exact derivation structure depends on the wallet and descriptor.
Receiving and Change Branches
HD wallets commonly separate receiving addresses from change addresses.
A simplified structure might look like:
/0/*
for receiving addresses.
And:
/1/*
for change addresses.
The wallet can therefore derive:
Receiving
/0/0
/0/1
/0/2
…
and:
Change
/1/0
/1/1
/1/2
…
This allows wallet software to generate many addresses from the same underlying key hierarchy.
A descriptor can encode these derivation rules so the wallet knows which addresses to monitor.
A More Realistic Descriptor
Now let’s put several pieces together.
You might encounter something conceptually similar to:
wpkh([f23a9b12/84h/0h/0h]xpub.../0/*)
Don’t worry about the entire string.
Let’s break it down.
wpkh()
The wallet uses a native SegWit P2WPKH output structure.
[f23a9b12/84h/0h/0h]
This gives key-origin information.
xpub...
This is an extended public key.
/0/*
This tells the wallet how to derive a sequence of child keys.
Together, the descriptor gives software much more information than an individual Bitcoin address.
It describes the relationship between the key material, derivation structure, and output type.
Why Descriptors Are Useful for Watch-Only Wallets
Suppose you have a hardware wallet containing your private keys.
You don’t want your desktop computer to possess those private keys.
However, you still want the desktop to:
- Generate receiving addresses
- Monitor incoming Bitcoin
- Calculate wallet balances
- Construct transactions
- Prepare PSBTs
A descriptor containing the appropriate public information can help the computer perform those tasks.
The hardware wallet remains responsible for signing.
This creates a clean division of responsibilities.
Desktop wallet
→ Watches and prepares
Hardware wallet
→ Verifies and signs
Bitcoin network
→ Records the final transaction
Descriptor Wallets vs. Legacy Wallets
Bitcoin Core historically supported older wallet structures that didn’t rely entirely on descriptors.
Modern Bitcoin Core wallets use descriptor-based wallets for new wallet creation.
The move toward descriptors improves wallet interoperability because the wallet’s script and key-derivation structure can be represented explicitly.
This is particularly important when working with:
- SegWit
- Taproot
- Multisig
- Watch-only wallets
- Hardware wallets
- Advanced wallet recovery
Bitcoin Core’s documentation explains that descriptor wallets use output descriptors to determine which scripts belong to the wallet. (github.com)
A Simple Mental Model
If descriptor syntax still looks confusing, remember this:
Bitcoin Script
Defines what conditions must be satisfied to spend Bitcoin.
Descriptor
Describes how those scripts and keys are constructed or identified.
Bitcoin Address
Provides a convenient destination representation for receiving Bitcoin.
Private Key
Provides the secret needed to authorize spending.
PSBT
Provides a standardized way to move a transaction through the signing process.
These technologies are different, but they work together.
Why Descriptors Matter More as Bitcoin Gets More Advanced
Bitcoin started with relatively simple transactions.
Today, users can build systems involving:
- Hardware wallets
- Multisig
- Taproot
- Watch-only wallets
- Offline signing
- Collaborative custody
- Complex spending policies
As wallet structures become more sophisticated, simply saying:
“Here are my addresses.”
isn’t enough.
Software needs to understand the underlying structure.
Descriptors provide a standardized language for describing that structure.
What Comes Next?
We now understand the major descriptor functions:
pkh()
wpkh()
sh()
wsh()
multi()
sortedmulti()
tr()
We’ve also seen how extended public keys, derivation paths, key origins, watch-only wallets, and PSBTs fit into the bigger picture.
But there’s one final piece:
How do you actually use descriptors safely?
Why Descriptor Backups Matter
Imagine that you create a Bitcoin wallet using a hardware wallet.
Your Bitcoin is controlled by keys derived from your wallet’s seed.
You might assume that the seed phrase is all you need for recovery.
Sometimes it can be enough, but wallet recovery can become more complicated when additional information is needed to reproduce the same wallet structure.
For example, software may need to know:
- Which output type the wallet uses
- Which derivation path it follows
- Which extended keys are involved
- Whether the wallet uses multisig
- Which keys belong to the wallet
- Which addresses are receiving addresses
- Which addresses are change addresses
A descriptor can encode much of this information in a standardized form.
This is one reason descriptor-based wallet systems are useful for portability and recovery.
Seed Phrase vs. Descriptor
It’s important not to think of a descriptor as a replacement for your seed phrase.
They serve different purposes.
Seed phrase
Provides the secret foundation from which wallet keys can be derived.
Descriptor
Describes how keys and scripts are used to construct or recognize wallet outputs.
A simple way to visualize the relationship is:
Seed
↓
Keys
↓
Descriptor
↓
Wallet scripts and addresses
The exact relationship depends on the wallet architecture, but the general idea is that the seed provides secret key material while the descriptor describes wallet structure.
Why a Descriptor Can Help With Recovery
Suppose you have a wallet that uses native SegWit addresses.
Another wallet might instead expect a different address type.
Even if the underlying keys originate from the same seed, the resulting addresses may not be the same if the derivation path or output type differs.
A descriptor can explicitly tell compatible software what structure to reproduce.
For example, a descriptor could specify:
Native SegWit
Extended public key
Derivation path
Address branch
This makes the wallet’s structure much less ambiguous.
Descriptor Backups Should Be Treated Carefully
A descriptor may contain public information, but that doesn’t automatically mean every descriptor is safe to publish.
Some descriptors can contain private key material.
Others may contain extended public keys and wallet structure information.
An extended public key does not provide the same spending capability as a private key, but it can still reveal information about a wallet’s addresses and transaction history when combined with blockchain data.
Therefore, treat wallet descriptors as sensitive wallet information.
A good general rule is:
Never share a descriptor unless you understand exactly what information it contains.
And if it contains private keys, treat it with the same seriousness as other private wallet backups.
Watch-Only Wallets and Descriptors
One of the most useful applications of descriptors is creating watch-only wallets.
Suppose your Bitcoin private keys are stored on a hardware wallet.
You want your computer to monitor the wallet.
The computer doesn’t need your private keys just to watch the blockchain.
Instead, it can use appropriate public wallet information, including a descriptor containing extended public keys.
The computer can then derive the relevant public addresses and monitor them.
This creates a useful separation:
Hardware wallet
→ Holds signing keys
Watch-only wallet
→ Monitors wallet activity
Bitcoin network
→ Records transactions
Bitcoin Core’s hardware-wallet documentation demonstrates importing public descriptors into a watch-only descriptor wallet so the computer can track balances and construct transactions without holding the private keys.
Descriptors and PSBTs Work Together
If you’ve just read our PSBT guide, this connection is worth remembering.
Descriptors and PSBTs aren’t competing technologies.
They solve different problems.
A descriptor describes the wallet’s structure.
A PSBT carries transaction information through a signing workflow.
For example:
Descriptor
“This wallet uses these keys and this spending structure.”
↓
Wallet software
“Create a transaction spending one of those outputs.”
↓
PSBT
“Here is the transaction that needs to be reviewed and signed.”
↓
Hardware wallet
“Verify and sign it.”
↓
Final transaction
“Broadcast it to Bitcoin.”
Bitcoin Core’s external-signer workflow illustrates this relationship: the wallet builds a PSBT, includes key-origin information, passes the PSBT to the signer, and then finalizes the transaction when sufficient signatures are available.
Descriptors and Multisig Recovery
Descriptors become even more important when dealing with multisig.
Consider a 2-of-3 wallet.
There are three participants:
Alice
Bob
Charlie
The wallet requires any two signatures.
A descriptor can describe:
- The required signature threshold
- The participating public keys
- Their derivation information
- The output type
- The key ordering
A real Bitcoin Core multisig descriptor can look conceptually like:
wsh(sortedmulti(2,...))
The important parts are:
wsh
Describes the P2WSH output structure.
sortedmulti
Describes the multisig policy with deterministic key ordering.
2
Two signatures are required.
Keys
Identify the participating signing keys.
Bitcoin Core’s multisig documentation uses descriptor-based definitions for multisig wallets and notes that sortedmulti provides deterministic key ordering, helping participants recreate the same wallet structure consistently.
Why Key Ordering Matters in Multisig
This is an easy detail to overlook.
Suppose three people have public keys:
A
B
C
One participant constructs the multisig script as:
A → B → C
Another accidentally constructs it as:
C → A → B
Even though the same keys are involved, the resulting script can differ because the key order is part of the script construction.
A deterministic sorting convention helps avoid this problem.
That’s one reason sortedmulti() is useful.
Instead of asking every participant to manually agree on an ordering, the descriptor can specify deterministic ordering.
This is particularly valuable when a multisig wallet needs to be reconstructed after a device is lost.
Descriptor Checksums
Remember the checksum we discussed in Part 1?
It becomes particularly important when copying descriptors.
A descriptor can be long.
A single accidental character can change its meaning.
A checksum provides software with a way to detect errors.
You may see a descriptor ending with something like:
#abcdef12
The section after # is the checksum.
Bitcoin Core’s documentation explains that its getdescriptorinfo RPC can calculate the checksum, which can then be appended to the descriptor.
The checksum isn’t an encryption mechanism.
It doesn’t make the descriptor secret.
Its purpose is to help detect errors.
What Happens If You Lose the Descriptor?
The answer depends on the wallet.
Some wallets store descriptors internally and can export them.
Others may derive them again from wallet information.
Modern wallet software can also provide dedicated backup and recovery mechanisms.
Therefore, you shouldn’t assume that every wallet requires you to manually write down a descriptor.
Instead, check what backup information your specific wallet recommends.
The important lesson is:
Understand what your wallet needs for complete recovery before you depend on the backup.
For advanced wallets, this may involve more than simply knowing that a seed exists.
Descriptor Wallets and Bitcoin Core
Bitcoin Core has increasingly moved toward descriptor-based wallets.
Modern Bitcoin Core workflows use descriptors to define the scripts and keys that belong to wallets.
This makes the wallet’s structure more explicit.
For example, a descriptor can tell Bitcoin Core:
Which output type to watch
Which keys to derive
Which addresses to monitor
Whether outputs are internal or external
How spending conditions are constructed
Bitcoin Core documentation also provides tools for importing descriptors and configuring ranges of derived addresses.
Descriptor Range and Address Discovery
You may see something like:
/0/*
inside a descriptor.
The wildcard indicates that the wallet can derive a sequence of child keys.
For example:
/0/0
/0/1
/0/2
/0/3
and so on.
A wallet therefore doesn’t need a separate descriptor for every individual receiving address.
Instead, one ranged descriptor can describe a whole sequence.
This is particularly useful when restoring or importing a watch-only wallet.
The wallet software can scan a defined range of derived addresses to find activity.
What About Change Addresses?
A wallet typically needs to distinguish between external receiving addresses and internal change addresses.
A descriptor can represent these different branches.
A simplified example is:
External
/0/*
Internal
/1/*
The exact paths depend on the wallet’s descriptor.
Bitcoin Core’s hardware-wallet examples demonstrate separate descriptors for external and internal branches when importing extended public keys into a watch-only wallet.
This is another reason descriptors are more powerful than simply keeping a list of addresses.
Can You Create a Descriptor From an Address?
Yes, but there’s an important limitation.
An address represents a particular output destination.
A descriptor can describe that destination using the addr() expression.
BIP 385 defines:
addr(ADDRESS)
as a descriptor that represents the output script produced by that address.
For example, conceptually:
addr(bc1q...)
means:
“Describe the output script associated with this address.”
However, that doesn’t magically recover the private key or complete wallet structure behind the address.
An address remains an address.
What Is raw()?
BIP 385 also defines a raw() descriptor.
For example:
raw(HEX)
This allows a raw Bitcoin output script to be represented as a descriptor.
The hexadecimal data represents the script itself.
This can be useful when software needs to work with output scripts that don’t fit neatly into the more common descriptor expressions.
In other words:
addr() starts with an address.
raw() starts with a script.
Both can represent existing Bitcoin output structures within the descriptor framework.
Common Descriptor Mistakes
Let’s look at some mistakes beginners should avoid.
Mistake 1: Thinking a Descriptor Is a Private Key
A descriptor is not automatically a private key.
It describes wallet output structure.
However, some descriptors can contain private key information, so always check what you’re handling.
Mistake 2: Treating a Descriptor Like a Seed Phrase
A descriptor and seed phrase aren’t interchangeable.
A seed provides secret key material.
A descriptor describes how wallet keys and scripts are organized.
Mistake 3: Losing the Descriptor Structure
If you’re using an advanced wallet, don’t assume that knowing the seed alone automatically means every wallet detail will be recovered exactly as before.
Understand the wallet’s recovery requirements.
Mistake 4: Changing Descriptor Characters
Don’t manually edit a descriptor unless you know exactly what you’re changing.
A single character can alter the descriptor.
The checksum can help detect accidental changes.
Mistake 5: Ignoring Key Ordering in Multisig
Multisig participants should use the exact same descriptor and key ordering rules.
A mismatch can result in participants generating different wallet structures.
Mistake 6: Sharing Sensitive Descriptors
Never publicly post a descriptor containing private key material.
Even public-only descriptors can reveal useful information about your wallet.
Treat wallet metadata carefully.
Are Descriptors Necessary for Every Bitcoin User?
No.
If you’re using a simple wallet application, you may never need to manually interact with a descriptor.
Your wallet may handle the entire process automatically.
But descriptors become increasingly useful when you’re dealing with:
- Hardware wallets
- Bitcoin Core
- Multisig
- Watch-only wallets
- Offline signing
- Advanced wallet recovery
- Custom scripts
- Wallet interoperability
So you don’t need to become a descriptor expert to use Bitcoin.
But understanding what descriptors do can make advanced Bitcoin concepts much easier to understand.
Frequently Asked Questions
What is a Bitcoin output descriptor?
A Bitcoin output descriptor is a standardized expression that describes a set of Bitcoin output scripts and the keys or derivation information associated with them.
It acts like a blueprint for how wallet software can construct or recognize outputs.
Is a descriptor the same as a Bitcoin address?
No.
An address generally represents a particular destination.
A descriptor can describe a broader wallet structure, including how multiple addresses or scripts are generated.
Is a descriptor the same as an xpub?
No.
An xpub is an extended public key.
A descriptor can contain an xpub along with information about how that key should be used.
So an xpub can be one component of a descriptor.
Can a descriptor spend Bitcoin?
A descriptor itself doesn’t spend Bitcoin.
It describes the keys and scripts involved in controlling outputs.
Actual spending requires the necessary private-key signatures or other valid authorization.
Can someone steal Bitcoin using my xpub?
An xpub does not normally provide the private-key capability required to spend the associated Bitcoin.
However, sharing an xpub can expose wallet information, including derived addresses and potentially transaction history.
For privacy reasons, don’t share extended public keys unnecessarily.
Can a descriptor contain a private key?
Yes, depending on how it is constructed.
A descriptor can contain private key expressions.
Therefore, you should inspect what you’re handling before sharing or storing it.
What does wpkh() mean?
wpkh() represents a native SegWit Pay-to-Witness-Public-Key-Hash output.
It is commonly associated with native SegWit addresses.
What does tr() mean?
tr() represents a Taproot output descriptor.
It can describe a Taproot output using an internal key and, in more advanced cases, a Taproot script tree.
What does sortedmulti() mean?
sortedmulti() represents a multisignature policy where the participating keys are sorted according to the descriptor’s deterministic ordering rules.
It can help different participants recreate the same multisig wallet structure consistently.
Are descriptors encrypted?
No.
A descriptor is a structured representation of wallet information.
It isn’t automatically encrypted simply because it contains cryptographic information.
Final Takeaway
Bitcoin output descriptors may look intimidating at first.
But their purpose is surprisingly simple.
They give wallet software a standardized way to describe:
Keys
Derivation paths
Output types
Scripts
Spending conditions
Wallet branches
Once you understand that, expressions such as:
wpkh(...)
sh(wpkh(...))
wsh(sortedmulti(...))
and:
tr(...)
start to make sense.
Descriptors also connect several Bitcoin technologies we’ve already covered.
HD wallets provide hierarchical key derivation.
Bitcoin Script defines spending conditions.
Multisig allows multiple keys to control Bitcoin.
PSBT moves transactions through the signing process.
Descriptors provide a standardized way to describe the keys and scripts behind those wallet structures.
That makes descriptors an important piece of modern Bitcoin wallet infrastructure.
You may never manually type one.
But if you use hardware wallets, multisig, watch-only wallets, Bitcoin Core, or advanced self-custody tools, there’s a good chance descriptors are working behind the scenes.
The key lesson is simple:
A Bitcoin address tells you where Bitcoin can be sent.
A private key proves you can authorize spending.
A descriptor describes the wallet’s structure and spending conditions that connect those pieces together.
Once you understand that relationship, many of the more advanced features of Bitcoin wallets become much easier to understand.
