390: Allow repeated participant pubkeys #1867

pull achow101 wants to merge 1 commits into bitcoin:master from achow101:390-clarifications changing 1 files +3 −1
  1. achow101 commented at 8:36 pm on June 5, 2025: member
    As posted to the mailing list, 390 should allow participant public keys to be repeated.
  2. jonatack added the label Proposed BIP modification on Jun 5, 2025
  3. in bip-0390.mediawiki:62 in 6020858dfc outdated 
    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>.
    rkrux commented at 9:24 am on June 6, 2025:

    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)"
    achow101 commented at 6:05 pm on June 6, 2025:

    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.

  4. rkrux commented at 9:27 am on June 6, 2025: contributor
    ACK 6020858dfcf35cddd0929e89acd23ab57a5b9caf
  5. achow101 force-pushed on Jun 6, 2025
  6. in bip-0390.mediawiki:62 in 19c46bd188 outdated 
    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>.
    murchandamus commented at 6:59 pm on June 6, 2025:

    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?

    achow101 commented at 7:18 pm on June 6, 2025:

    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.

    ajtowns commented at 9:51 am on June 11, 2025:
    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).
    w0xlt commented at 5:36 pm on June 12, 2025:

    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).
    achow101 commented at 6:28 pm on June 12, 2025:

    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.

  7. rkrux approved
  8. rkrux commented at 8:55 am on June 7, 2025: contributor
    ACK 19c46bd
  9. theStack approved
  10. theStack commented at 10:46 am on June 10, 2025: contributor
    ACK 19c46bd1887b3348d23659661e10a3c44c0af9e1
  11. harding commented at 6:49 pm on June 10, 2025: contributor

    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.

  12. achow101 force-pushed on Jun 12, 2025
  13. asim1019 commented at 10:32 pm on June 17, 2025: none
    Review don
  14. achow101 commented at 5:54 pm on June 18, 2025: member
    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.
  15. jonatack commented at 6:19 pm on June 18, 2025: member
    Not that it has much reach, but I also asked on X and had no reply: https://x.com/jonatack/status/1930728964005265563
  16. bitcoin deleted a comment on Jun 18, 2025
  17. achow101 force-pushed on Jun 18, 2025
  18. achow101 commented at 7:22 pm on June 18, 2025: member
    Dropped the second commit as the wording seems to be confusing, will open a new PR with the clarification from the second commit.
  19. achow101 force-pushed on Jun 18, 2025
  20. achow101 commented at 7:31 pm on June 18, 2025: member
    Added a test vector for the duplicate participant.
  21. 390: Allow repeated participant pubkeys 530b91d86b
  22. achow101 force-pushed on Jun 18, 2025
  23. murchandamus approved
  24. murchandamus commented at 7:33 pm on June 18, 2025: contributor
    LGTM
  25. murchandamus merged this on Jun 18, 2025
  26. murchandamus closed this on Jun 18, 2025
  27. rkrux commented at 10:47 am on June 19, 2025: contributor

    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.

  28. murchandamus renamed this:
    390: Allow repeated participant pubkeys and disallow ranged participants with aggregate derivation.
    390: Allow repeated participant pubkeys
    on Jun 19, 2025


achow101 rkrux murchandamus ajtowns w0xlt theStack harding asim1019 jonatack

Labels
Proposed BIP modification

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bips. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2025-07-29 12:10 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me