This is a proposal for human-readable descriptors of sets of scriptPubKeys, together with information about how to spend them ("solving"), and optionally also private keys.
It aims to address the issue that public keys, xpubs, and their secret key versions do not carry any information about the type of scripts to be used. Historically, this has been addressed by implying certain types of scripts with keys (P2PKH and P2PK, in particular, and later extended with P2WPKH and P2SH-P2WPKH). However, this approach is:
- Ambiguous: importing keys across software versions may miss certain scripts
- Scales badly: every new script type needs to be taken into account for all keys, which affects filtering approaches like BIP37 and BIP157 badly
- Inflexible: there is no straightforward way to extend this to multisignatures or other scripts, despite those being a standard feature in many pieces of software
Recent proposals have been made to improve upon this by adding an address type of public and/or private keys, but that does not address the last point above - making them only usable for certain subsets of use cases. Instead, this proposal aims for a language that is sufficiently flexible to serve as the primary source of information about what outputs are treated as belonging to a certain wallet, and not just a shorthand notation for importing keys with associated scripts. The intent is to remove the need for importing scripts and keys entirely, and instead make the wallet just be a list of these descriptors plus associated metadata. Its goal is to cover every script Bitcoin Core can currently sign for, be compatible with hardware wallets and BIP174, and be easily extensible to new scripts (including larger multisig constructions, HTLCs, ...) and even future softforks that extend the scripting language.
It is not designed for maximal compactness or error recovery. However, proposals for those could be described in terms of syntactic sugar that translates to this proposal's language. It also does not include metadata related to a script's usage, such as birth date, or whether it is treated as change or not.
The reference documentation has moved to the Bitcoin Core doc/descriptors.md file.
@Sjors Nothing should be repeated within one descriptor, and I prefer to keep individual descriptors standalone. Perhaps we can design a syntactic sugar layer on top to give some more human-readable form later on.
@Sjors Of course labels need to be supported, but they don't fit in this layer. Descriptors just describe the outputs, and are generally static data. Labels are not relevant in all places where descriptors are useful (say for an offline signer, or scantxoutset, or ...), and are generally dynamic data (needs to be backed up after every operation, while the descriptors don't change). I expect that a wallet will consist of descriptors with some metadata ("use this descriptor for new change outputs"), and then labels separately from that.