Thanks Andrew for proposing the BIP, I have used this syntax in Sparrow for some time now. I find a single, compact descriptor for a wallet is important when copying out as a backup, particularly onto durable media. More so when it is a multisig wallet that ideally requires a backup of all the xpubs. Multipath descriptors as proposed in this BIP address this need well. Craig On Tue, Jul 26, 2022 at 11:51 PM Andrew Chow via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi All, > > I would like to propose a BIP that de-duplicates and simplifies how we > represent descriptors for receiving and change addresses. Under the > existing BIPs, this requires two descriptors, where the vast majority of > the descriptors are the same, except for a single derivation path > element. This proposal allows descriptors to have a single derivation > path element that can specify a pair of indexes. Parsers would then > expand these into two almost identical descriptors with the difference > being that the first uses the first of the pair of indexes, and the > second uses the second. > > The proposed notation is ``. As an example, > `wpkh(xpub.../0/<0;1>/*)` would be expanded into `wpkh(xpub.../0/0/*)` > and `wpkh(xpub.../0/1/*)`. > > This also works for descriptors involving multiple keys - the first > element in every pair is used for the first descriptor, and the second > element of each pair in the second descriptor. > > The full text of the BIP can be found at > > https://github.com/achow101/bips/blob/bip-multipath-descs/bip-multipath-descs.mediawiki > and also copied below. An implementation of it to Bitcoin Core is > available at https://github.com/bitcoin/bitcoin/pull/22838. > > Any feedback on this would be appreciated. > > Thanks, > Andrew Chow > > --- > > 
>    BIP: multipath-descs
>    Layer: Applications
>    Title: Multipath Descriptor Key Expressions
>    Author: Andrew Chow 
>    Comments-Summary: No comments yet.
>    Comments-URI:
> https://github.com/bitcoin/bips/wiki/Comments:BIP-multipath-descs
>    Status: Draft
>    Type: Informational
>    Created: 2022-07-26
>    License: BSD-2-Clause
>
> > ==Abstract== > > This document specifies a modification to Key Expressions of Descriptors > that are described in BIP 380. > This modification allows Key Expressions to indicate BIP 32 derivation > path steps that can have multiple values. > > ==Copyright== > > This BIP is licensed under the BSD 2-clause license. > > ==Motivation== > > Descriptors can describe the scripts that are used in a wallet, but > wallets often require at least two descriptors for all of the scripts > that they watch for. > Wallets typically have one descriptor for producing receiving addresses, > and the other for change addresses. > These descriptors are often extremely similar - they produce the same > types of scripts, derive keys from the same master key, and use > derivation paths that are almost identical. > The only differences are in the derivation path where one of the steps > will be different between the descriptors. > Thus it is useful to have a notation to represent both descriptors as a > single descriptor where one of the derivation steps is a pair of values. > > ==Specification== > > For extended keys and their derivations paths in a Key Expression, BIP > 380 states: > > * xpub encoded extended public key or xprv encoded > extended private key (as defined in BIP 32) > ** Followed by zero or more /NUM or /NUMh path > elements indicating BIP 32 derivation steps to be taken after the given > extended key. > ** Optionally followed by a single /* or /*h final > step to denote all direct unhardened or hardened children. > > This is modifed to state: > > * xpub encoded extended public key or xprv encoded > extended private key (as defined in BIP 32) > ** Followed by zero or more /NUM or /NUMh path > elements indicating BIP 32 derivation steps to be taken after the given > extended key. > ** Followed by zero or one / (NUM may be > followed by h to indicated a hardened step) path element > indicating a pair of BIP 32 derivation steps to be taken after the given > extended key. > ** Followed by zero or more /NUM or /NUMh path > elements indicating BIP 32 derivation steps to be taken after the given > extended key. > ** Optionally followed by a single /* or /*h final > step to denote all direct unhardened or hardened children. > > When a / is encountered, parsers should produce two > descriptors where the first descriptor uses the first NUM, and > a second descriptor uses the second NUM. > > The common use case for this is to represent descriptors for producing > receiving and change addresses. > When interpreting for this use case, wallets should use the first > descriptor for producing receiving addresses, and the second descriptor > for producing change addresses. > For this use case, the element will commonly be the value /<0;1> > > ==Test Vectors== > > TBD > > ==Backwards Compatibility== > > This is an addition to the Key Expressions defined in BIP 380. > Key Expressions using the format described in BIP 380 are compatible > with this modification and parsers that implement this will still be > able to parse such descriptors. > However as this is an addition to Key Expressions, older parsers will > not be able to understand such descriptors. > > This modification to Key Expressions uses two new characters: < > and ;. > These are part of the descriptor character set and so are covered by the > checksum algorithm. > As these are previously unused characters, old parsers will not > accidentally mistake them for indicating something else. > > ==Reference Implementation== > > https://github.com/bitcoin/bitcoin/pull/22838 > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >