Skip to content

Instantly share code, notes, and snippets.

Last active January 9, 2019 13:52
Show Gist options
  • Save sipa/e3d23d498c430bb601c5bca83523fa82 to your computer and use it in GitHub Desktop.
Save sipa/e3d23d498c430bb601c5bca83523fa82 to your computer and use it in GitHub Desktop.
Output script descriptors

Output script descriptors

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/ file.

Copy link

Sjors commented Jul 12, 2018

I know you're not trying to optimize for storage, but this could get pretty repetitive and long hex strings hurt human-readability. Maybe allow xpub variable names, or allow using a fingerprint (xpub-abcdef01) ?

Do you also want to support labels? Or is that too much of a can of worms, since in that case one should also add transaction labels? Label metadata is quite important for keeping track of the real world, and quite hard to port between wallets.

Copy link

sipa commented Jul 17, 2018

@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.

Copy link

sipa commented Jul 18, 2018

Please don't use this comment feature for discussion going forward. Without any form of notifications it's not very useful for back-and-forths.

Copy link

kanzure commented Jul 27, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment