390: Allow repeated participant pubkeys#1867
Conversation
6020858 to
19c46bd
Compare
bip-0390.mediawiki
Outdated
| For these <tt>musig()</tt> expressions, the KEY expressions contained within must be xpubs or derived from | ||
| xpubs, and cannot contain child derivation as specified by a <tt>/*</tt>, <tt>/*'</tt>, or <tt>/*h</tt>. | ||
| This restriction on KEY expression child derivation applies even when the derivation steps following the | ||
| <tt>musig()</tt> do not include <tt>/*</tt>. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
It might be worth adopting the term "wildcard index" from bip 88? Then you could specify it as "the KEY expression contained within a 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).
There was a problem hiding this comment.
Adding an example like the one mentioned above can make the text clearer.
| For these <tt>musig()</tt> expressions, the KEY expressions contained within must be xpubs or derived from | |
| xpubs, and cannot contain child derivation as specified by a <tt>/*</tt>, <tt>/*'</tt>, or <tt>/*h</tt>. | |
| This restriction on KEY expression child derivation applies even when the derivation steps following the | |
| <tt>musig()</tt> do not include <tt>/*</tt>. | |
| For these <tt>musig()</tt> expressions, the KEY expressions contained within must be xpubs or derived from | |
| xpubs, and cannot contain child derivation as specified by a <tt>/*</tt>, <tt>/*'</tt>, or <tt>/*h</tt>. | |
| This restriction on KEY expression child derivation applies even when the derivation steps following the | |
| <tt>musig()</tt> do not include <tt>/*</tt>. (Ex: `musig(xpub1/*,xpub2/*)/3/4` is disallowed). |
There was a problem hiding this comment.
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 19c46bd 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. |
19c46bd to
6791838
Compare
|
I haven't heard anyone say that this change would be an issue for them. Were there any comments about it after the Optech recap? If not, then I think this is ready to be merged. |
|
Not that it has much reach, but I also asked on X and had no reply: https://x.com/jonatack/status/1930728964005265563 |
6791838 to
46aa9f6
Compare
|
Dropped the second commit as the wording seems to be confusing, will open a new PR with the clarification from the second commit. |
46aa9f6 to
4d544e5
Compare
|
Added a test vector for the duplicate participant. |
4d544e5 to
530b91d
Compare
rkrux
left a comment
There was a problem hiding this comment.
Post merge ACK
390: Allow repeated participant pubkeys and disallow ranged participants with aggregate derivation.
The PR title can be updated though to remove the second clause since the second commit was removed.
As posted to the mailing list, 390 should allow participant public keys to be repeated.