path: root/09/3a894336616ad1e445a3f90e57887eaaf79e56

Return-Path: <craigraw@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4D1FCC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 27 Jul 2022 07:57:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 10C0381A30
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 27 Jul 2022 07:57:35 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 10C0381A30
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=Fcb7RPHY
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id KncEbnm7uqU0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 27 Jul 2022 07:57:33 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 4986081A33
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com
 [IPv6:2a00:1450:4864:20::12d])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 4986081A33
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 27 Jul 2022 07:57:33 +0000 (UTC)
Received: by mail-lf1-x12d.google.com with SMTP id y11so25808296lfs.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 27 Jul 2022 00:57:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=11w7yMHmjYtxhE9CsHBia2Q5nlLKL/yIF84ktxI0H3E=;
 b=Fcb7RPHYtQ2gP5qunzaYS0AEozUonMK7d6dTD6pbAvJTwwle0wv/t8SuOUH27r/CvE
 CNcB7Qc+uNNH5yejLOhS3UHgZDPpup7MU+vBXnA7m+V/WzvsvOa2iANzztF6BXZy+srP
 1LueiNgUOgt8eXYPuFSvGdJCh7xwH19ZfqlroAVbLhBordJcaRlBbdLC9CI4XDda4Z2+
 A5z/HH47Urz3vDvY0HQgkJactx16uxVwzO653uLKDxw4Oxqs4gJezI6icy99OIzSmluK
 3JG1m9JqWcx9k5aC5ybLId19QfeSVJ2l2f8tAxO0Pm2gZKByPHl0rNeC1xL2ZXU4fXnU
 3J5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=11w7yMHmjYtxhE9CsHBia2Q5nlLKL/yIF84ktxI0H3E=;
 b=Dw5XPHXJt1JDBMTA1AyruyYja12l6nEFI2dL4hehA1jmjF3jOF4V7K3beDdsyDhgBb
 +a3XdZOtDY+aeKGJdwKLQxzGwh+6sC5Oi8jSPNl6QQ5l6RWpLi5GQuzqkMtRfEsG7HUC
 gAF5wgl8S0PbxHP8/JpWWSzwrWZbhK+Zo5R9xY5aqhRM9RLYPfBczzgnR4I9BuGAxy2t
 MstluhrwZDvB44pqy40iFHu90F+kVTPGteZ0XI+NwB6OIneZlDCWJXljZtCF1TCjgq5K
 yNdMCAnHUsgw9QeVlBlAh4csUecoG+Do+bZi74AMzvVGVd4pRHvbtMLpfFTsqJ0sYW/R
 7jAA==
X-Gm-Message-State: AJIora8ABbcfEdAfJaH5nzc3oDx7+eqi85nawb5AaTyLJOYBi3vcn2dx
 2j16l3k8A+j+MEkieNJwv8/OC7fGw64YfG30DQ+WUo1g
X-Google-Smtp-Source: AGRyM1vGNgm6Q4/31m1y/vrJe1RdQQJwJjhR2my03aKk2VsE5alsofpuxci53/yzoBNjPLZ+2wq9OnoGyiHCIsGtwsE=
X-Received: by 2002:a05:6512:3592:b0:48a:8c8d:44c8 with SMTP id
 m18-20020a056512359200b0048a8c8d44c8mr5601422lfr.436.1658908650818; Wed, 27
 Jul 2022 00:57:30 -0700 (PDT)
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"
X-Mailman-Approved-At: Wed, 27 Jul 2022 11:17:43 +0000
Subject: Re: [bitcoin-dev] BIP Proposal: Receiving and Change Derivation
 Paths in a Single Descriptor
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jul 2022 07:57:35 -0000

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