Billy Tetrud [ARCHIVE] on Nostr: 📅 Original date posted:2022-08-03 📝 Original message:@Dmitry > various software ...
📅 Original date posted:2022-08-03
📝 Original message:@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 at 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 at 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220803/bc75c220/attachment-0001.html>;
📝 Original message:@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 at 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 at 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220803/bc75c220/attachment-0001.html>;