As posted to the mailing list, 390 should allow participant public keys to be repeated.
A question that came up during implementation review was whether musig(xpub1/*,xpub2/*)/a/b/c) is allowed. My interpretation of the text is that it is not, and I’ve added a sentence to explicitly say it is not.
57@@ -58,6 +58,8 @@ following the <tt>musig()</tt> expression cannot contain
58 <tt>/NUMh</tt> or <tt>/NUM'</tt> derivation steps nor <tt>/*h</tt>, or <tt>/*'</tt> child derivation.
59 For these <tt>musig()</tt> expressions, the KEY expressions contained within must be xpubs or derived from
60 xpubs, and cannot contain child derivation as specified by a <tt>/*</tt>, <tt>/*'</tt>, or <tt>/*h</tt>.
61+The KEY expressions cannot contain child derivation even when the derivation steps following the <tt>musig()</tt>
62+do not include <tt>/*</tt>.
I guess this statement is fine following the previous one but when I look at this statement alone, I think it can explicitly mention ranged derivation like below:
0- The KEY expressions cannot contain child derivation even when
1+ The KEY expressions cannot contain ranged child derivation even when
Following is a valid example from the implementation PR that can contradict this new statement.
0"rawtr(musig(xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/0,xpub68NZiKmJWnxxS6aaHmn81bvJeTESw724CRDs6HbuccFQN9Ku14VQrADWgqbhhTHBaohPX4CjNLf9fq9MYo6oDaPPLPxSb7gwQN3ih19Zm4Y)/1)"
The term “ranged” does not actually ever appear in any of the specs, so using it here may be confusing as well.
Since the previous sentence discusses ranged derivation, I’ve reworded the sentence to be referring to that to be clearer.
57@@ -58,6 +58,8 @@ following the <tt>musig()</tt> expression cannot contain
58 <tt>/NUMh</tt> or <tt>/NUM'</tt> derivation steps nor <tt>/*h</tt>, or <tt>/*'</tt> child derivation.
59 For these <tt>musig()</tt> expressions, the KEY expressions contained within must be xpubs or derived from
60 xpubs, and cannot contain child derivation as specified by a <tt>/*</tt>, <tt>/*'</tt>, or <tt>/*h</tt>.
61+This restriction on KEY expression child derivation applies even when the derivation steps following the
62+<tt>musig()</tt> do not include <tt>/*</tt>.
I find this hard to understand.
Does this mean that one musig() expression may not include two keys where one of the keys is a child derivation of the other key?
No, it’s saying that musig(xpub1/*,xpub2/*)/3/4 is disallowed.
I do not see how you could have interpreted it in a way that this was talking about KEY expressions being relative to each other.
musig() expression cannot include a wildcard index (ie a /*, /*', or /*h)”? (Or if not that, some other way of talking about derivation templates that generate many keys versus a fixed derivation that always generates a particular key).
Adding an example like the one mentioned above can make the text clearer.
0For these <tt>musig()</tt> expressions, the KEY expressions contained within must be xpubs or derived from
1xpubs, and cannot contain child derivation as specified by a <tt>/*</tt>, <tt>/*'</tt>, or <tt>/*h</tt>.
2This restriction on KEY expression child derivation applies even when the derivation steps following the
3<tt>musig()</tt> do not include <tt>/*</tt>. (Ex: `musig(xpub1/*,xpub2/*)/3/4` is disallowed).
It might be worth adopting the term “wildcard index” from bip 88?
Perhaps, but I’d prefer to do that in a followup.
Adding an example like the one mentioned above can make the text clearer.
I don’t like adding examples to the specification section. However, I did add a failure test case for it.
ACK 19c46bd1887b3348d23659661e10a3c44c0af9e1
FYI, the Friday, June 13th, Optech newsletter will be relaying @achow101’s mailing list request for feedback about this change to give it wider exposure, so if there’s still an outstanding concern that someone has already implemented duplicate checking, it might be useful to wait another week to merge this.
