Hi Antoine and Billy, Thank you for your comments and for looking into the proposal. On Mon, 9 May 2022 at 12:36, darosior wrote: > 1. The `` 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 `/` 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 [1] https://github.com/bitcoin/bitcoin/issues/17190#issuecomment-543845642 [2] https://github.com/bitcoin/bips/blob/master/bip-0384.mediawiki