Re: [bitcoin-dev] BIP Proposal: Receiving and Change Derivation Paths in a Single Descriptor

From: Pavol Rusnak <stick@satoshilabs•com>
To: Andrew Chow <achow101-lists@achow101•com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP Proposal: Receiving and Change Derivation Paths in a Single Descriptor
Date: Tue, 26 Jul 2022 23:56:10 +0200	[thread overview]
Message-ID: <CAF90AvmdfzpE2TrXHMD4=DJZcq2U1muCcBZndMiRQLw1p57kYQ@mail.gmail.com> (raw)
In-Reply-To: <d97c9d44-730e-cbb4-ce8b-19bdf1ea1e2d@achow101.com>

[-- Attachment #1: Type: text/plain, Size: 6112 bytes --]

Thanks Andrew for this BIP. We've been already using this for quite some
time for Trezor in production.

Just one clarification: Should <NUM;NUM;NUM>, <NUM;NUM;NUM;NUM>, ... also
work or we only aim to support only tuples of exactly two values?

On Tue, 26 Jul 2022 at 23:51, 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 `<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@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@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
Co-Founder, SatoshiLabs

[-- Attachment #2: Type: text/html, Size: 8131 bytes --]