1. The `<NUM;NUM>` optimization for the common usecase of using 2 descriptors at different derivation indices
for receive and change. [1]
2. The `/**` optimization for the common usecase of `/<0;1>` for point 1).
[...]
I'm not so sure about the second point. Is another deviation from the standard worth it just for saving 3
characters?
I agree with the concerns of both you and Billy on the `\**` syntax, and it is certainly not a crucial part of the proposal, as it is arguably redundant once `\<0;1>` is available.
I have been using it since before the `\<0;1>` syntax was proposed (afaik), and I thought I would leave it mostly for the sake of optimizing the UX in the most common use cases. I think that
sh(sortedmulti(2,@0/**,@1/**,@2/**))
is quite a lot more readable (especially on a small screen) than
sh(sortedmulti(2,@0/<0;1>/*,@1/<0;1>/*,@2/<0;1>/*))
Apart from the additional 5 characters per placeholder, there are a lot more numbers to parse for the user.
Yet, I'm not too attached to the feature as it is probably not very useful in taptrees. For the future, I expect further improvements will come from the hardware wallets analyzing the wallet policy and recognizing the commonly used patterns. No reason to show the full taptree of a complex 3-of-5 multisig setup − you can just say "Taproot 3-of-5 multisig". Show the full taptree policy should be reserved for the 1% of advanced use-cases that are not in the catalogue.
Slightly off-topic, but my impression is that descriptors are outgrowing their original scope (probably the reason for sipa's comments[1] on the early proposals for multiple derivation paths in one descriptor).
I think there is a case to be made for keeping the language of descriptors limited to represent either (1) a single output, or (2) a list of outputs with the `/*` syntax; in this interpretation, the `/<m;n>` syntax would entirely be on a separate layer (the `combo` descriptor[2] would also be extraneous in this interpretation).
I tried to design the policy wallet language in a way that is agnostic to these details of descriptor specs (since I target a _subset_ of descriptors, it will work either way).
However, why does it need to be a change to the descriptor language? It looks a lot like something that needs
to be handled at the application level with key aliasing.
Key aliasing is not part of descriptors; therefore, "descriptors with key aliasing" are still a language on top of descriptors.
Adding key aliases will indeed be a great UX improvement, but in my opinion it is better built on top of wallet policies, rather than within the language itself.
Note that by separating the wallet descriptor template from the keys themselves, such a feature is already facilitated. Moreover, wallet policies separate the KEY expressions of descriptors into two semantically relevant parts: only the xpub and its origin info goes into the "vector of key information", while the receive/change part of the derivation is kept in the placeholder (therefore in the descriptor template). Adding restrictions is also useful: `xpub/1/2/3/4/<0;1>/5/6/*` might be valid miniscript, but supporting this kind of thing would be (arguably) unreasonable and a lot more complicated for hardware wallets; therefore, placeholders and key informations are a lot more limited in the wallet policy language than their miniscript counterpart.
While I understand that descriptors are designed with a maximum flexibility mindset, a minimized feature set is very valuable for hardware wallets, and I believe it can be done with little to no practical loss of use cases. Restrictions can be lifted in future versions when the need arises.
I think to better suit the needs of both hardware and software wallets, you need both the extensions and the restrictions. That's why I propose to keep them separated, rather than suggesting changes to descriptors.
Unrelated question, since you mentioned `musig2` descriptors in this context. I thought Musig2 wasn't really
feasible for hardware signing devices, especially stateless ones. Do you think/know whether it is actually
possible for a HW to take part in a Musig2?
I certainly have some more homework to do on musig2, and for this proposal I was only concerned with making sure the wallet policy language won't break with future upgrades to descriptors.
Yet, as far as I understand , the complications for hardware wallets are (1) possible lack of good quality randomness, and (2) need to keep state during a signing session. Ledger signers have a hardware TRNG, and while the design is generally stateless, there is flash memory that can be used to store the secret nonce during a signing session (or, more likely, a few parallel signing sessions). Therefore, I don't think there are technical blockers for musig2.
Salvatore