Can R/r in Musig be derived from only seeds and message hashes? I am wondering if the first two roundtrips of pre-committing and then revealing R/r in MuSig signing can be moved to the keygen phase and made deterministic. That reduces the amount of messages that need to be exchanged; since keygen is done only once, we want to expand that phase. This would be especially useful for HD wallets: at the expense of making wallet creation more complicated, signing would need fewer interactions.

The musig paper on page 10-11, specifies the following (from perspective of signer 1):

MuSig scheme

Key generation


generates private key x1 and corresponding public key X1
sends X1
receives Xi


Signing (specifically the part about agreeing on Ri)


sends t1=Hcom(R1)
receives ti 
sends R1
receives Ri
checks that Hcom(Ri)==ti


r1 is specified to be random.
Signing includes three rounds of interaction, two of which is used for the above steps (agreeing on Ri).
I want to move these steps to the keygen phase.



A HD wallet would presumably use BIP32 to generate X1.
Can we use BIP32 for deriving Ri/ri too?

Consider the following scheme instead.
(from cosigners 1's perspective)

Proposed HD scheme

HD wallet setup phase


generates xprv y1 and corresponding xpub Y1
generates xprv k1 and corresponding xpub K1
sends xpub Y1
sends u1=H(K1)
receives xpub Yi
receives ui
sends xpub K1
receives xpub Ki
checks that H(Ki)==ui


Key generation


from xprv y1 along some BIP32 path p, derive private key x1 and public key X1
from xpub Yi along same BIP32 path p, derive public key Xi
from xprv K1 along same BIP32 path p, derive private key j1 and public key J1
from xpub Ki along same BIP32 path p, derive public key Ji. 


Signing (specifically the part about agreeing on Ri)


compute r1=j1+hash(m) and R1=J1+hash(m)*G
compute Ri=Ji+hash(m)*G


This approach only has one round of interaction during signing (sending si, omitted as its not changed from what is described in the paper).

I have read the derandomization section, but the explanation for why it doesn't work requires Ri to be chosen by the attacker. If we make it deterministically derived, and BIP32 is safe, then this attack does not apply. The paper states "each signer must ensure that whenever any Rj sent by other cosigners or the message m changes, his ri value changes unpredictably. As long as f is deterministic, this implies a circular dependency in the choice of random values."

Where is this circular dependency? The f from RFC 6979 only depends on key and m.
The construction you're suggesting will likely work as long as you don't sign more than one message. By effectively choosing the R points ahead of time, you've constructed a single-show signature.

However, the derivation you're using for the different R values is pointless. It's not enough that you don't reuse R values; you can't use multiple related R values either. All the R values you are constructing are related through a single linear equation. That is sufficient for an attacker (who knows about the relation) to derive the private key from seeing two signatures.