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

From: Billy Tetrud <billy.tetrud@gmail•com>
To: Dmitry Petukhov <dp@simplexum•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: Wed, 3 Aug 2022 20:16:52 -0500	[thread overview]
Message-ID: <CAGpPWDaSsAn3GPoYdJmdJ6iW6M6G_2G8ua1cONhjSRRdSog8Pg@mail.gmail.com> (raw)
In-Reply-To: <20220728114016.2ff78722@simplexum.com>

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

@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.
>
> В 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
>

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