Allowing Duplicate Keys in BIP 390 musig() Expressions
3 messages, 3 Jun 2025. Started by Ava Chow.
Ava Chow (2), Boris Nagaev
Hi All,
In implementing musig() descriptor expressions, I realized that the restriction "Repeated participant public keys are not allowed" is a bit complicated to implement. While I don't see why anyone would want to duplicate keys, MuSig2 does allow duplicate participant keys and allowing them would make the implementation of musig() expressions much easier. Thus I'd like to propose changing the BIP to remove this restriction.
Has anyone implemented musig() expressions yet with this restriction, and would removing it be a significant breaking change to anyone? If not, I'll make the change to the BIP in a few days.
Thanks,
Ava
Hi Ava,
Is it safe to allow multiple participants to have the same public key? If deterministic nonce generation is used (deriving each participant's nonce from the message, the set of public keys, and the participant's private key), duplicate public keys would lead to identical nonces.
While this may not be catastrophic (since they are signing the same message and the private key likely can't be extracted) it still seems risky. Identical nonces can have unexpected consequences, and I'm not sure if all security assumptions would still hold.
Curious what you think.
Best, Boris
On Tue, Jun 3, 2025 at 6:08 PM 'Ava Chow' via Bitcoin Development Mailing List <bitcoindev@googlegroups•com> wrote:
Quoted text (24 lines)
> > Hi All, > > In implementing musig() descriptor expressions, I realized that the > restriction "Repeated participant public keys are not allowed" is a bit > complicated to implement. While I don't see why anyone would want to > duplicate keys, MuSig2 does allow duplicate participant keys and > allowing them would make the implementation of musig() expressions much > easier. Thus I'd like to propose changing the BIP to remove this > restriction. > > Has anyone implemented musig() expressions yet with this restriction, > and would removing it be a significant breaking change to anyone? If > not, I'll make the change to the BIP in a few days. > > Thanks, > > Ava > > > -- > You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/08dbeffd-64ec-4ade-b297-6d2cbeb5401c%40achow101.com.
Hi Boris,
BIP 327 explicitly allows for duplicate participant pubkeys, so as long as all signing procedures follow the BIP, everything will be fine. Also, BIP 327 explicitly warns against deterministic nonces for reasons unrelated to duplicate pubkeys.
Although, allowing duplicates does bring up an additional issue with the MuSig2 PSBT fields as these inherently do not allow duplicate pubkeys.
Ava
On 06/03/2025 02:26 PM, Nagaev Boris wrote:
Quoted text (47 lines)
> Hi Ava, > > Is it safe to allow multiple participants to have the same public key? > If deterministic nonce generation is used (deriving each participant's > nonce from the message, the set of public keys, and the participant's > private key), duplicate public keys would lead to identical nonces. > > While this may not be catastrophic (since they are signing the same > message and the private key likely can't be extracted) it still seems > risky. Identical nonces can have unexpected consequences, and I'm not > sure if all security assumptions would still hold. > > Curious what you think. > > Best, > Boris > > On Tue, Jun 3, 2025 at 6:08 PM 'Ava Chow' via Bitcoin Development > Mailing List <bitcoindev@googlegroups•com> wrote: >> Hi All, >> >> In implementing musig() descriptor expressions, I realized that the >> restriction "Repeated participant public keys are not allowed" is a bit >> complicated to implement. While I don't see why anyone would want to >> duplicate keys, MuSig2 does allow duplicate participant keys and >> allowing them would make the implementation of musig() expressions much >> easier. Thus I'd like to propose changing the BIP to remove this >> restriction. >> >> Has anyone implemented musig() expressions yet with this restriction, >> and would removing it be a significant breaking change to anyone? If >> not, I'll make the change to the BIP in a few days. >> >> Thanks, >> >> Ava >> >> >> -- >> You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com. >> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/08dbeffd-64ec-4ade-b297-6d2cbeb5401c%40achow101.com. > > > -- > Best regards, > Boris Nagaev