Craig Raw [ARCHIVE] on Nostr: š Original date posted:2022-07-27 š Original message:Thanks Andrew for ...
š
Original date posted:2022-07-27
š Original message: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 at 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 `<a;b>`. 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
>
> ---
>
> <pre>
> BIP: multipath-descs
> Layer: Applications
> Title: Multipath Descriptor Key Expressions
> Author: Andrew Chow <andrew at achow101.com>
> 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
> </pre>
>
> ==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:
>
> * <tt>xpub</tt> encoded extended public key or <tt>xprv</tt> encoded
> extended private key (as defined in BIP 32)
> ** Followed by zero or more <tt>/NUM</tt> or <tt>/NUMh</tt> path
> elements indicating BIP 32 derivation steps to be taken after the given
> extended key.
> ** Optionally followed by a single <tt>/*</tt> or <tt>/*h</tt> final
> step to denote all direct unhardened or hardened children.
>
> This is modifed to state:
>
> * <tt>xpub</tt> encoded extended public key or <tt>xprv</tt> encoded
> extended private key (as defined in BIP 32)
> ** Followed by zero or more <tt>/NUM</tt> or <tt>/NUMh</tt> path
> elements indicating BIP 32 derivation steps to be taken after the given
> extended key.
> ** Followed by zero or one <tt>/<NUM;NUM></tt> (<tt>NUM</tt> may be
> followed by <tt>h</tt> 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 <tt>/NUM</tt> or <tt>/NUMh</tt> path
> elements indicating BIP 32 derivation steps to be taken after the given
> extended key.
> ** Optionally followed by a single <tt>/*</tt> or <tt>/*h</tt> final
> step to denote all direct unhardened or hardened children.
>
> When a <tt>/<NUM;NUM></tt> is encountered, parsers should produce two
> descriptors where the first descriptor uses the first <tt>NUM</tt>, and
> a second descriptor uses the second <tt>NUM</tt>.
>
> 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 <tt>/<0;1></tt>
>
> ==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: <tt><</tt>
> and <tt>;</tt>.
> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220727/91885f13/attachment-0001.html>;
š Original message: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 at 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 `<a;b>`. 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
>
> ---
>
> <pre>
> BIP: multipath-descs
> Layer: Applications
> Title: Multipath Descriptor Key Expressions
> Author: Andrew Chow <andrew at achow101.com>
> 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
> </pre>
>
> ==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:
>
> * <tt>xpub</tt> encoded extended public key or <tt>xprv</tt> encoded
> extended private key (as defined in BIP 32)
> ** Followed by zero or more <tt>/NUM</tt> or <tt>/NUMh</tt> path
> elements indicating BIP 32 derivation steps to be taken after the given
> extended key.
> ** Optionally followed by a single <tt>/*</tt> or <tt>/*h</tt> final
> step to denote all direct unhardened or hardened children.
>
> This is modifed to state:
>
> * <tt>xpub</tt> encoded extended public key or <tt>xprv</tt> encoded
> extended private key (as defined in BIP 32)
> ** Followed by zero or more <tt>/NUM</tt> or <tt>/NUMh</tt> path
> elements indicating BIP 32 derivation steps to be taken after the given
> extended key.
> ** Followed by zero or one <tt>/<NUM;NUM></tt> (<tt>NUM</tt> may be
> followed by <tt>h</tt> 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 <tt>/NUM</tt> or <tt>/NUMh</tt> path
> elements indicating BIP 32 derivation steps to be taken after the given
> extended key.
> ** Optionally followed by a single <tt>/*</tt> or <tt>/*h</tt> final
> step to denote all direct unhardened or hardened children.
>
> When a <tt>/<NUM;NUM></tt> is encountered, parsers should produce two
> descriptors where the first descriptor uses the first <tt>NUM</tt>, and
> a second descriptor uses the second <tt>NUM</tt>.
>
> 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 <tt>/<0;1></tt>
>
> ==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: <tt><</tt>
> and <tt>;</tt>.
> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220727/91885f13/attachment-0001.html>;