@bigspider: could you please take a look?

ACK db8bad7

Well spotted, thanks @scgbckbone!

off-topic Q: @bigspider was it considered to drop /** syntax completely, forbid non-ranged keys and instead @0 would be shortcut for @0/<0;1>/* ? Is there any use case for non-ranged keys in descriptor anyways ?

I sympathize with possibly dropping /**, since the main rationale was to make it more readable in the common case for small screens - but in the long term, I expect the solution will be to find ways of not showing the descriptor template at all, at least in most cases.

The rest of the suggestion (make @0 immediately imply @0/<0;1>/*) would unfortunately lose an important feature: wallets like Liana are already using @0/<0;1>/*, @0/<2;3>/*, etc. in the same wallet policy to identify different spending paths without having to repeat the same root xpub multiple times (which indeed wallet policies forbid). This allows wallets to semantically distinguish between cosigners (= entries in the vector of key info) vs spending conditions (= occurrences of the same key placeholder in different parts of the Script, e.g. different tapleaves). I expect this to be extremely handy in practice, versus the alternative of using multiple xpubs for the same cosigner.

Moreover, I think keeping the syntax similar to descriptors, minimizing the differences between the two standards, helps keeping things more easily extensible.
For example, Blockstream Jade added support for /* as a custom valid derivation, which they need for wallets that were already in use at the time wallet policies were proposed. Not having this kind of flexibility might have made it challenging for them to adopt the standard.

The rest of the suggestion (make @0 immediately imply @0/<0;1>/) would unfortunately lose an important feature: wallets like Liana are already using @0/<0;1>/, @0/<2;3>/*, etc. in the same wallet policy to identify different spending paths without having to repeat the same root xpub multiple times (which indeed wallet policies forbid). This allows wallets to semantically distinguish between cosigners (= entries in the vector of key info) vs spending conditions (= occurrences of the same key placeholder in different parts of the Script, e.g. different tapleaves). I expect this to be extremely handy in practice, versus the alternative of using multiple xpubs for the same cosigner.

how does BIP-388 forbid @0/<0;1>/*, @0/<2;3>/* ? After reading it few times it seemed that it is allowed. My current implementation supports @0/<0;1>/*, @0/<2;3>/* in wallet policy, heh

I do not see how symbolizing @0/<0;1>/* with @0 instead of currently used @0/** (with condition that only ranged extended keys are allowed in policy) prohibits liana from doing it.

off-topic Q:

Feel free to continue this discussion here.

how does BIP-388 forbid @0/<0;1>/*, @0/<2;3>/* ? After reading it few times it seemed that it is allowed. My current implementation supports @0/<0;1>/*, @0/<2;3>/* in wallet policy, heh

Oh yes, it does allow that, in fact it's expected; what's forbidden is to have the same xpub in different keys in the key information vector.
I thought you meant that @i would never have an additional derivation in the descriptor template, while I now understand that you mean something like:

• @i refers to just the xpub if it's followed by one or more derivation steps;
• @i refers to xpub/<0;1>/* otherwise.

I do not see how symbolizing @0/<0;1>/* with @0 instead of currently used @0/** (with condition that only ranged extended keys are allowed in policy) prohibits liana from doing it.

Changing the meaning of @i based on where it appears would make the grammar more complicated and confusing; for example, you lose the property that you can go from the descriptor template to the descriptor by just replacing each @i with its xpub (and /** ==> /<0;1>/*.

Note that @0 without derivation is already used today, for example, in a key expression like musig(@0,@1,...)/<0;1>/*.

The goal of /** was in fact to have a clean, easy to parse shortcut for /<0;1>/* with the least visual impact possible, without risking such syntactical quirks.

Changing the meaning of @i based on where it appears would make the grammar more complicated and confusing

agreed... thanks for the info!