path: root/e2/be40abbda8ef8cc84fa67b5eef30ef50c37b86

Return-Path: <stick@satoshilabs.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 436EEC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Jul 2022 21:56:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 25AAC8175D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Jul 2022 21:56:24 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 25AAC8175D
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=satoshilabs.com header.i=@satoshilabs.com
 header.a=rsa-sha256 header.s=google header.b=R2s25VRX
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, 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 xs6SJ9Pi2MSb
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Jul 2022 21:56:22 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org A239D8175B
Received: from mail-yw1-x1133.google.com (mail-yw1-x1133.google.com
 [IPv6:2607:f8b0:4864:20::1133])
 by smtp1.osuosl.org (Postfix) with ESMTPS id A239D8175B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Jul 2022 21:56:22 +0000 (UTC)
Received: by mail-yw1-x1133.google.com with SMTP id
 00721157ae682-31f379a0754so54123857b3.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 26 Jul 2022 14:56:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=satoshilabs.com; s=google;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=HWuHhDEDS92p9vT7EdAzwe36oWZSlMa7y6/AcO1R4Pw=;
 b=R2s25VRXgc4pEdd0NxhksEcgVWLYlUXJY3cq/DVOqqG2GjqX3dsUeuJrtkvKVFUhR5
 ME2UPAf7xM331BUOcBe7dCnbWgdoueoLMwDa0OXp63Ppu9IWi8qZpsl7p/N3UJpnmilh
 t9k8kqC6Efy7YAdXwzBi/d44Xl5IpWOKRxN6jiyiNresvmt9hefb5FiNR3reImHrQUS2
 FeluKVensr+c1sr+1WUCih2f4sHmcEID/FNlKEm5C0jkFE0XIarUqn2eskxbBdCntLqa
 xpDiVMZTsJEmbnskdlU2gbW1BoeEJ9Su4j9w7lROcN7rdQYjr0EmXW5TdG7soc2NvZUA
 EGtA==
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=HWuHhDEDS92p9vT7EdAzwe36oWZSlMa7y6/AcO1R4Pw=;
 b=kY0IhWB+Lo2SKbjn5xEYwyfx4D7PrARVDITDpIcd9Zy1jK52RmjYgQrDP6BjzjBST3
 sY8Q6427x5j+EUjv6FiZ8UKJJyIFYwDBFU6TyNi+DQQ+at5YVF8wpKJ6KqyFeO68uNsA
 D+cCw/iXbFjGfvsqIKFK2zAqCNsCCi6BjfGirFjejyCL7HUBWqaG7SQgzfwR9462/4Et
 WGL45MqafVZfPhcG4aieItgH08nt1LbQqyWy1tFFRZAZbsDLNCePx4Gmu0qngb9SdCiu
 IkMtmnPRDPMTOVsPBLYrwS+M5kS9rbYWPWfvVRL9u5+g9uL/KLmzPNYe7cM4+U2IrWPS
 eq1w==
X-Gm-Message-State: AJIora+VlozFR58OYy/w4eTFRe7U5d3v4Slik7o869ujVrihA8TCsaxQ
 FnYu77oxZz6o0BqN4teitvh1TozDvvyC8FrKGCpmJq5Qtu743w==
X-Google-Smtp-Source: AGRyM1sr7oigzwhWbfy8Y5c/+R7vt4mWTbRRhnzF3Ar4MpE4nLtsJggG1BIvryT8XHnKIj4Pfd+p5let7Q7Qn57f7T4=
X-Received: by 2002:a81:81c1:0:b0:31e:7378:960c with SMTP id
 r184-20020a8181c1000000b0031e7378960cmr16649656ywf.266.1658872581617; Tue, 26
 Jul 2022 14:56:21 -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: Pavol Rusnak <stick@satoshilabs.com>
Date: Tue, 26 Jul 2022 23:56:10 +0200
Message-ID: <CAF90AvmdfzpE2TrXHMD4=DJZcq2U1muCcBZndMiRQLw1p57kYQ@mail.gmail.com>
To: Andrew Chow <achow101-lists@achow101.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000f4913605e4bc5e81"
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: Tue, 26 Jul 2022 21:56:24 -0000

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

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

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

<div dir=3D"ltr"><div>Thanks Andrew for this BIP. We&#39;ve been already=C2=
=A0using this for quite some time for Trezor in production.</div><div><br><=
/div><div>Just one clarification: Should &lt;NUM;NUM;NUM&gt;, &lt;NUM;NUM;N=
UM;NUM&gt;, ... also work or we only aim to support only tuples of exactly =
two values?</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" clas=
s=3D"gmail_attr">On Tue, 26 Jul 2022 at 23:51, Andrew Chow via bitcoin-dev =
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-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><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div></di=
v><div>Best Regards / S pozdravom,</div><div><br></div><div>Pavol &quot;sti=
ck&quot; Rusnak</div><div>Co-Founder, SatoshiLabs</div></div></div></div></=
div>

--000000000000f4913605e4bc5e81--