path: root/23/2cb0850c98673a93caa0b68177b86b40f79bfd

Return-Path: <fresheneesz@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 27089C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Aug 2022 01:17:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id E97904053E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Aug 2022 01:17:10 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org E97904053E
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=LnhDSZvO
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 smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id NmdIwijGgDuu
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Aug 2022 01:17:09 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 92402403FD
Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com
 [IPv6:2607:f8b0:4864:20::a33])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 92402403FD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  4 Aug 2022 01:17:09 +0000 (UTC)
Received: by mail-vk1-xa33.google.com with SMTP id b81so9545509vkf.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 03 Aug 2022 18:17:09 -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=DrTvFUBC0P+D3/Ad/LffkPUQM3jeSFWM8xYkNrmlBiE=;
 b=LnhDSZvOhdoJjh2pi6OHz5SQgWB/po2iB9Jp15AhQ8b4QBB+CSaf6cxzboD8zjLSRt
 tgW/pi1e9xX2UaFBMUVLbV+yFgR1JC5OPQgaksaR0W8bljX3sn6jWbKRJpXKH7f/Vgd+
 7VTV66DudLcw1Xtgv0B87nz+8j+u34vxTMxlEAha1NpVcNvlY2l+c1ZFp88kPEkGsiMO
 e/IQiYP9GgQnOMgPNd4bDlpuDI/jb5cgUscv3wwox44hKOyecmewnzbJn8G6TFsI25wD
 kdb6immMvg47g+TnMCVCcEsJ+jsjmzjbVTkHLXf1DSNa4FMqWfUe7YDj/tdZ+pjdsHQ8
 lqtw==
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=DrTvFUBC0P+D3/Ad/LffkPUQM3jeSFWM8xYkNrmlBiE=;
 b=6zcqtzMN2GPg41lV5swyN6dCMxJD5k7LkhuWSmTbTl5d9eIKkTkgutTyfpB1hN32Jo
 NTRSigoLPEZLWosxW83OcQms54RVSPXcpDcE65DNXw0YCgTatEfA37IhNzn2B9TDuXw4
 PYxXv//fCf7NHVDmNbreybNkuZHs2L0FS5neUQCB5AYbi+zPagvG0+ZRzJoaAy32UN6n
 PZ3n5PYcQMDU571/m7b4lVGhlI2ACf3YGvyxJ0ub23qxFQi6/UZgNwRShNS+jVOclr8n
 QvfFpcF99BKIGObUmgmxWegJXLjSMoTmOS05rBgJ060/9wNEobfv3+U/PZHobbx7UJ14
 vyDQ==
X-Gm-Message-State: ACgBeo001R7d5iAAW0lOWsv7Uv3HaAdpkwyo0sxDBKsNpuCl4tAcfu+r
 P6dLNitFrxdq/O3mPODg3QQmY9j95ixM1JsvrvTP7jwievQ=
X-Google-Smtp-Source: AA6agR7eNQ0Cn4uxaBlMYaNtfAAuO6Dw8NUWlBLaBZp4Ih+736fSs6dGiR9ubCXMIBwyzAxaldh7I7u1JIiwGcwMm0U=
X-Received: by 2002:a1f:1bd1:0:b0:377:b693:bb39 with SMTP id
 b200-20020a1f1bd1000000b00377b693bb39mr4858747vkb.22.1659575827939; Wed, 03
 Aug 2022 18:17:07 -0700 (PDT)
MIME-Version: 1.0
References: <7bded922-5067-caee-e5be-9f620cfc7404@achow101.com>
 <20220728114016.2ff78722@simplexum.com>
In-Reply-To: <20220728114016.2ff78722@simplexum.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Wed, 3 Aug 2022 20:16:52 -0500
Message-ID: <CAGpPWDaSsAn3GPoYdJmdJ6iW6M6G_2G8ua1cONhjSRRdSog8Pg@mail.gmail.com>
To: Dmitry Petukhov <dp@simplexum.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000b3c60f05e5601b4d"
X-Mailman-Approved-At: Thu, 04 Aug 2022 10:16:54 +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: Thu, 04 Aug 2022 01:17:11 -0000

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

@Dmitry
>  various software might start to use extra indexes in a tuple for their
own non-standard purposes

This will be true regardless of whether the spec allows or doesn't allow
tuples of length more than 2. In fact, any other tuple other than <1;2>
will be nonstandard. We can't prevent people from using standards in
use-case-specific ways, and we can't prevent people from creating
non-standard extensions of standards.

> Wallet software that wishes to utilize non-standard extra indexes beyond
'receive' and 'change' should use separate descriptors instead for these
extra indexes.

What benefit would that gain? The wallets would still be doing something
non-standard and interpreting those indexes however they want. A descriptor
format is simply defining a space of address derivation paths. It is not
describing in any way what each path is intended for - those are
conventions outside the scope of this BIP IMO. Defining the conventions of
derivation path indexes should be a separate BIP. Single responsibility
principle.

On Thu, Jul 28, 2022 at 5:15 AM Dmitry Petukhov via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The issue with tuples of lenth more than two is that the purpose for
> indexes beyond 'receive' and 'change' are not established, and
> therefore various software might start to use extra indexes in a tuple
> for their own non-standard purposes. This is bound to create
> incompatibilities where different wallet software that import the same
> descriptor would use those addresses for different purposes.
>
> Even if some auxiliary standard emerges for the meanings of extra
> indexes, since the indexes in the tuple are listed without omissions (no
> "<0;1;;;3>" allowed), all software will need to be aware of the
> existence of these purposes and define indexes for them: if one wishes
> to utilize position 3 in such a tuple, they will need to define an index
> for position 2 as well.
>
> I'd expect that emergence of new widely-used purposes for indexes would
> be a very rare event, and a separate BIP for each purpose wouldn't be
> excessive.
>
> I'd say that bip-multipath-descs should say that extra indexes are OK
> for address discovery (for scanning of the addresses of a wallet), but
> it should say that any interpretation of the purpose of such indexes
> and deriving new addresses at these indexes are strongly discouraged.
>
> Wallet software that wishes to utilize non-standard extra indexes beyond
> 'receive' and 'change' should use separate descriptors instead for
> these extra indexes.
>
> And when a new established purpose emerges for the next position in the
> index tuple, a new BIP should be made that defines such position.
>
> The BIP for position 3 would naturally come after the BIP for position
> 2, and thus software that implemnents BIP for position 3 would be aware
> of the previous BIP and will at least know to choose some index for
> position 2.
>
> =D0=92 Wed, 27 Jul 2022 14:58:28 +0000
> Andrew Chow via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> wrote:
>
> > I've updated the BIP text to allow arbitrary length tuples.
> >
> > On 07/27/2022 04:44 AM, Pavol Rusnak wrote:
> >
> > > On Wed, 27 Jul 2022 at 00:28, Andrew Chow
> > > <achow101-lists@achow101.com> wrote:
> > >> However I don't see why this couldn't generalize to any sized
> > >> tuples. As long as the tuples are all the same length, and the
> > >> limit is one tuple per key expression, then we don't get any
> > >> combinatorial blowup issues.
> > >
> > > I think it's worthwhile to generalize for any sized tuples. I don't
> > > have any existing particular use case in mind, because BIP-44,
> > > BIP-84, etc. are fine with just using <0;1>, but there might be
> > > some upcoming standards in the future that will want to introduce
> > > more sub-paths.
> > >
> > > --
> > >
> > > Best Regards / S pozdravom,
> > >
> > > Pavol "stick" Rusnak
> > > Co-Founder, SatoshiLab
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>@Dmitry<br></div>&gt;=C2=A0
various software might start to use extra indexes in a tuple for their own =
non-standard purposes<div><br></div><div>This will be true regardless of wh=
ether the spec allows or doesn&#39;t allow tuples of length more than 2. In=
 fact, any other tuple other than &lt;1;2&gt; will be nonstandard. We can&#=
39;t prevent=C2=A0people=C2=A0from using standards in use-case-specific=C2=
=A0ways, and we can&#39;t prevent people from creating non-standard extensi=
ons of standards.=C2=A0</div><div><br></div><div>&gt; Wallet software that =
wishes to utilize non-standard extra indexes beyond &#39;receive&#39; and &=
#39;change&#39; should use separate descriptors instead for these extra ind=
exes.</div><div><br></div><div>What benefit would that gain? The wallets wo=
uld still be doing something non-standard and interpreting=C2=A0those index=
es however they want. A descriptor format is simply defining a space of add=
ress derivation paths. It is not describing in any way what each path is in=
tended for - those are conventions outside the scope of this BIP IMO. Defin=
ing the conventions of derivation path indexes=C2=A0should be a separate BI=
P. Single responsibility principle.</div></div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jul 28, 2022 at 5:15 AM Dm=
itry Petukhov via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linux=
foundation.org" target=3D"_blank">bitcoin-dev@lists.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">The =
issue with tuples of lenth more than two is that the purpose for<br>
indexes beyond &#39;receive&#39; and &#39;change&#39; are not established, =
and<br>
therefore various software might start to use extra indexes in a tuple<br>
for their own non-standard purposes. This is bound to create<br>
incompatibilities where different wallet software that import the same<br>
descriptor would use those addresses for different purposes.<br>
<br>
Even if some auxiliary standard emerges for the meanings of extra<br>
indexes, since the indexes in the tuple are listed without omissions (no<br=
>
&quot;&lt;0;1;;;3&gt;&quot; allowed), all software will need to be aware of=
 the<br>
existence of these purposes and define indexes for them: if one wishes<br>
to utilize position 3 in such a tuple, they will need to define an index<br=
>
for position 2 as well.<br>
<br>
I&#39;d expect that emergence of new widely-used purposes for indexes would=
<br>
be a very rare event, and a separate BIP for each purpose wouldn&#39;t be<b=
r>
excessive.<br>
<br>
I&#39;d say that bip-multipath-descs should say that extra indexes are OK<b=
r>
for address discovery (for scanning of the addresses of a wallet), but<br>
it should say that any interpretation of the purpose of such indexes<br>
and deriving new addresses at these indexes are strongly discouraged.<br>
<br>
Wallet software that wishes to utilize non-standard extra indexes beyond<br=
>
&#39;receive&#39; and &#39;change&#39; should use separate descriptors inst=
ead for<br>
these extra indexes.<br>
<br>
And when a new established purpose emerges for the next position in the<br>
index tuple, a new BIP should be made that defines such position.<br>
<br>
The BIP for position 3 would naturally come after the BIP for position<br>
2, and thus software that implemnents BIP for position 3 would be aware<br>
of the previous BIP and will at least know to choose some index for<br>
position 2.<br>
<br>
=D0=92 Wed, 27 Jul 2022 14:58:28 +0000<br>
Andrew Chow via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&g=
t;<br>
wrote:<br>
<br>
&gt; I&#39;ve updated the BIP text to allow arbitrary length tuples.<br>
&gt; <br>
&gt; On 07/27/2022 04:44 AM, Pavol Rusnak wrote:<br>
&gt; <br>
&gt; &gt; On Wed, 27 Jul 2022 at 00:28, Andrew Chow<br>
&gt; &gt; &lt;<a href=3D"mailto:achow101-lists@achow101.com" target=3D"_bla=
nk">achow101-lists@achow101.com</a>&gt; wrote: <br>
&gt; &gt;&gt; However I don&#39;t see why this couldn&#39;t generalize to a=
ny sized<br>
&gt; &gt;&gt; tuples. As long as the tuples are all the same length, and th=
e<br>
&gt; &gt;&gt; limit is one tuple per key expression, then we don&#39;t get =
any<br>
&gt; &gt;&gt; combinatorial blowup issues.=C2=A0 <br>
&gt; &gt;<br>
&gt; &gt; I think it&#39;s worthwhile to generalize for any sized tuples. I=
 don&#39;t<br>
&gt; &gt; have any existing particular use case in mind, because BIP-44,<br=
>
&gt; &gt; BIP-84, etc. are fine with just using &lt;0;1&gt;, but there migh=
t be<br>
&gt; &gt; some upcoming standards in the future that will want to introduce=
<br>
&gt; &gt; more sub-paths.<br>
&gt; &gt;<br>
&gt; &gt; --<br>
&gt; &gt;<br>
&gt; &gt; Best Regards / S pozdravom,<br>
&gt; &gt;<br>
&gt; &gt; Pavol &quot;stick&quot; Rusnak<br>
&gt; &gt; Co-Founder, SatoshiLab=C2=A0 <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>

--000000000000b3c60f05e5601b4d--