A public Bitcoin descriptor packages an account's public key with instructions for constructing its addresses. The BitBoxApp provides these descriptors so compatible wallet software can follow an account without spending access. Sharing one reveals the addresses and activity it describes, including future activity, so its privacy consequences matter as much as its convenience.
To find and copy your own descriptor, follow the account-details guide.
What the descriptor adds to a public key
An extended public key lets software derive public keys. The software still needs to know how to use those keys to construct the intended Bitcoin addresses. A descriptor supplies that context: the script type, where the account key came from and which child addresses to follow.
For example, wpkh(...) specifies Native SegWit, while tr(...) specifies Taproot. The xpub inside either descriptor does not express that distinction by itself. If you copy only the key, another application may construct different addresses and miss the activity you expect.
The public descriptors exported by the BitBoxApp contain no private keys, cannot sign transactions and cannot replace a wallet backup. This limitation applies to these public exports: descriptors as a general technical format can also contain private keys.
Read a Native SegWit descriptor
This schematic example describes the fifth Native SegWit Bitcoin account on mainnet. The key and checksum are placeholders, so it cannot be imported into a wallet:
wpkh([56f89c3e/84'/0'/4']xpub.../<0;1>/*)#checksum| Part | Meaning |
|---|---|
wpkh(...) |
Construct Native SegWit addresses, also called P2WPKH. |
56f89c3e |
An example root fingerprint: a short reference to the wallet the key comes from. |
84'/0'/4' |
The origin path: Native SegWit, Bitcoin mainnet, account index four. Indexing starts at zero, making this the fifth account. |
xpub... |
The extended public key, abbreviated here, from which child public keys can be derived. |
<0;1> |
Follow both address branches: zero for receiving and one for change. |
* |
Vary the address index within each branch to derive many addresses. |
#checksum |
A placeholder for the actual eight-character checksum used to detect text errors. |
The two paths do different jobs. Inside the square brackets, 84'/0'/4' records how the account key was derived. After the key, /<0;1>/* tells the receiving application which child keys to derive from it. This receiving/change notation is called a multipath descriptor.
The fingerprint helps identify the wallet, but different wallets can share one because it is short. The checksum helps detect copying or formatting mistakes, but does not prove wallet identity or authenticity. Use the complete export from your selected account rather than an example.
Check what the receiving application supports
A descriptor can only be imported by software that supports its script type and notation. Support for Native SegWit, for example, does not establish support for Taproot or for the receiving/change multipath notation. Check the application's import instructions if it rejects the descriptor; removing parts to make it fit can change what it describes.
For Taproot, the BitBoxApp provides a descriptor and QR code without a separate Extended public key field or Bitcoin Verify on device button. Use its Taproot descriptor to follow that format's activity. A Native SegWit descriptor does not also include it.
Where the BitBoxApp offers extended-public-key comparison, the check concerns that key, not the complete descriptor. A successful key comparison or checksum check therefore does not verify every descriptor field.
Copying a descriptor shares account visibility
Use the complete descriptor only with software or services you trust with the account's financial history and future activity. Its QR code and screenshots containing it disclose the same information. Never provide recovery words, private keys or a wallet backup for a public account import.
If an application specifically requires a separate extended public key, check its account-format requirements. See extended public keys and their encodings for the difference between a key's prefix and the addresses it can describe.