@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-li...@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 >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
