MIME-Version: 1.0
References: <d97c9d44-730e-cbb4-ce8b-19bdf1ea1e2d@achow101.com>
In-Reply-To: <d97c9d44-730e-cbb4-ce8b-19bdf1ea1e2d@achow101.com>
From: Craig Raw <craigraw@gmail.com>
Date: Wed, 27 Jul 2022 09:57:19 +0200
Message-ID: <CAPR5oBNYgYzcxb4+8Qyw2_HO4uFWOAuJZwZ+8xNUzcLWdRYfcw@mail.gmail.com>
To: Andrew Chow <achow101-lists@achow101.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000d8ced605e4c4c47d"
Subject: Re: [bitcoin-dev] BIP Proposal: Receiving and Change Derivation
 Paths in a Single Descriptor
Precedence: list

--000000000000d8ced605e4c4c47d
Content-Type: text/plain; charset="UTF-8"

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 `<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
>

--000000000000d8ced605e4c4c47d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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

--000000000000d8ced605e4c4c47d--