You can't choose R if you provide posk

On Mon, Jul 24, 2023 at 10:31 AM Jonas Nick via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
>