BIP-0388: Fix test vector #1884

1. 
   scgbckbone commented at 10:45 am on June 30, 2025: contributor

   fix: descriptor in “Taproot wallet policy with sortedmulti_a and a miniscript leaf” test vector which incorrectly uses @0 from keys info without key origin derivation
2. fix: descriptor in "Taproot wallet policy with sortedmulti_a and a miniscript leaf" test vector which incorrectly uses @0 from keys info without key origin derivation db8bad7ac9
3. scgbckbone renamed this:
   Fix test vector
   BIP-0388: Fix test vector
   on Jun 30, 2025
4. 
   murchandamus commented at 6:17 pm on June 30, 2025: contributor

   @bigspider: could you please take a look?
5. murchandamus added the label Proposed BIP modification on Jun 30, 2025
6. murchandamus added the label Pending acceptance on Jun 30, 2025
7. 
   bigspider commented at 6:28 am on July 1, 2025: contributor

   ACK db8bad7ac9ed3ac858fdfadab7df77a77d55608b

   Well spotted, thanks @scgbckbone!

8. 
   scgbckbone commented at 12:29 pm on July 1, 2025: contributor

   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 ?
9. 
   bigspider commented at 1:35 pm on July 1, 2025: contributor

   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.

10. 
    scgbckbone commented at 4:13 pm on July 1, 2025: contributor

    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](/bitcoin-bips/contributor/0/)/<2;3>/* ? After reading it few times it seemed that it is allowed. My current implementation supports @0/<0;1>/*, [@0](/bitcoin-bips/contributor/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.

11. jonatack removed the label Pending acceptance on Jul 1, 2025
12. jonatack merged this on Jul 1, 2025
13. jonatack closed this on Jul 1, 2025

    ---

14. 
    jonatack commented at 8:21 pm on July 1, 2025: member

    off-topic Q:

    Feel free to continue this discussion here.

15. 
    bigspider commented at 2:17 am on July 2, 2025: contributor

    how does BIP-388 forbid @0/<0;1>/*, [@0](/bitcoin-bips/contributor/0/)/<2;3>/* ? After reading it few times it seemed that it is allowed. My current implementation supports @0/<0;1>/*, [@0](/bitcoin-bips/contributor/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.

16. 
    scgbckbone commented at 7:36 am on July 2, 2025: contributor

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

    agreed… thanks for the info!

Contributors
scgbckbone murchandamus bigspider jonatack

Labels
Proposed BIP modification