Hi Tom,
I'm not convinced that this works. As far as I know blind musig is still an open
research problem. What the scheme you propose appears to try to prevent is that
the server signs K times, but the client ends up with K+1 Schnorr signatures for
the aggregate of the server's and the clients key. I think it's possible to
apply a variant of the attack that makes MuSig1 insecure if the nonce commitment
round was skipped or if the message isn't determined before sending the nonce.
Here's how a malicious client would do that:
- Obtain K R-values R1[0], ..., R1[K-1] from the server
- Let
R[i] := R1[i] + R2[i] for all i <= K-1
R[K] := R1[0] + ... + R1[K-1]
c[i] := H(X, R[i], m[i]) for all i <= K.
Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that
c[0] + ... + c[K-1] = c[K].
- Send c[0], ..., c[K-1] to the server to obtain s[0], ..., s[K-1].
- Let
s[K] = s[0] + ... + s[K-1].
Then (s[K], R[K]) is a valid signature from the server, since
s[K]*G = R[K] + c[K]*a1*X1,
which the client can complete to a signature for public key X.
What may work in your case is the following scheme:
- Client sends commitment to the public key X2, nonce R2 and message m to the
server.
- Server replies with nonce R1 = k1*G
- Client sends c to the server and proves in zero knowledge that c =
SHA256(X1 + X2, R1 + R2, m).
- Server replies with s1 = k1 + c*x1
However, this is just some quick intuition and I'm not sure if this actually
works, but maybe worth exploring.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
