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
