BIP Proposals for Output Script Descriptors [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2021-08-05T20:49:43+00:00


Summary:

In a discussion on the bitcoin-dev mailing list, Sjors Provoost proposed adding a birth date or minimum block height to the BIP 32 and BIP 88 standards for Hierarchical Deterministic Path Templates. He suggested using a metadata format to track this information alongside descriptors.The Airgap Wallet Community supports metadata in their UR standards, which use CBOR's tagging capability. The UR standards also provide efficient transport via QR codes or URLs. Interested parties can learn more about these standards by watching a video on Blockchain Commons Technology Overview or reading articles on URs, including guides for key material and SSKRs, as well as UR Request & Response. Additionally, there are specs available on Uniform Resources (UR) and HD Keys. For further questions, individuals can visit the Airgapped Wallet Community on GitHub.Bitcoin Core developer Andrew Chow has proposed formalizing the Output Script Descriptors in a set of 7 BIPs. These descriptors are used to describe collections of output scripts and offer a generic solution to issues with wallet backups and exports. The 7 BIPs specify various descriptors such as non-segwit descriptors (pk, pkh, sh), segwit descriptors (wpkh, wsh), multisig descriptors (multi, sortedmulti), the taproot descriptor (tr), the combo descriptor, and opaque descriptors (raw, addr). The proposal also suggests including a birth date and metadata format to track birth data, gap limits, and other necessary information for future wallets. Another document outlines specifications for Bitcoin output script descriptors, specifically for P2WPKH and P2WSH formats (wpkh() and wsh() expressions), as well as P2PK, P2PKH, and P2SH formats (pk(), pkh(), and sh() expressions).There has been a debate on whether to use an apostrophe or 'h' in Bitcoin output script descriptors. Craig Raw argued that using an apostrophe allows for more whitespace and easier visual parsing, while David A. Harding countered that the difference in space usage is negligible and that using 'h' or 'H' avoids potential errors in shell-quoting and is more efficient for metal backups. Daniel Bayerdorffer of Numberall Stamp & Tool Co., Inc. recommended the Bitcoin Recovery Tag as a metal backup option that supports both apostrophes and 'h'. The discussion highlights the importance of considering user experience and practical considerations in the design of Bitcoin-related tools and protocols.The debate over using 'h' or an apostrophe in Bitcoin descriptors continued, with David A. Harding expressing concerns about using 'h' as it takes up more space and makes derivation paths and descriptors more difficult to read. However, Andrew Chow pointed out that the difference in space is only 0.7% and there are no issues with readability or transcription errors due to the use of a fixed character width font and checksums. Additionally, he mentioned that using apostrophes actually provides more whitespace and makes the path easier to parse visually. The real concern lies in using "-containing descriptors in a bourne-style shell, which can lead to loss of money. Ultimately, Raw agreed with Harding's points.David A. Harding proposed making "h"/"H" the preferred aliases instead of "'" in Bitcoin descriptors to improve user experience. However, Andrew Chow raised concerns about increased space usage and difficulty in reading descriptors and derivation paths. David suggested alternative options like completely eliminating "'", but it was not feasible due to widespread use of descriptors, or calculating the checksum over s/(h|H)/', which had been discussed before but not implemented due to the need for dumb checksum checkers that don't have to parse descriptors. In conclusion, the text was updated to use "h", but alternatives were still being considered.Andrew Chow has submitted a pull request to formalize Bitcoin Core's Output Script Descriptors into BIPs. The specifications are split into seven BIPs, with the first one providing general information and the rest specifying different descriptors. These descriptors offer a generic solution to issues with wallet backups by explicitly specifying script types and key derivation paths. They include non-segwit descriptors (pk, pkh, sh), segwit descriptors (wpkh, wsh), multisig descriptors (multi, sortedmulti), taproot descriptor (tr), combo descriptor, and opaque descriptors (raw, addr). Jeremy Rubin suggested collecting feedback through WIP PRs. Bitcoin Core has implemented pk(), pkh(), sh(), and tr() descriptors since version 0.17 and version 22.0.In an email exchange between Christopher Allen and Andrew Poelstra, the possibility of supporting time locks in descriptors other than 'raw' was discussed. Andrew mentioned that he expects miniscript to be a follow-up BIP that extends these descriptors and includes timelock functionality.


Updated on: 2023-08-02T04:16:38.460464+00:00