{"type":"rich","version":"1.0","title":"Erik Aronesty [ARCHIVE] wrote","author_name":"Erik Aronesty [ARCHIVE] (npub1y2…5taj0)","author_url":"https://yabu.me/npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2023-07-24\n🗒️ Summary of this message: The email discusses the potential vulnerabilities of a proposed scheme and suggests an alternative approach that may be worth exploring.\n📝 Original message:\nYou can't choose R if you provide posk\n\nOn Mon, Jul 24, 2023 at 10:31 AM Jonas Nick via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hi Tom,\n\u003e\n\u003e I'm not convinced that this works. As far as I know blind musig is still\n\u003e an open\n\u003e research problem. What the scheme you propose appears to try to prevent is\n\u003e that\n\u003e the server signs K times, but the client ends up with K+1 Schnorr\n\u003e signatures for\n\u003e the aggregate of the server's and the clients key. I think it's possible to\n\u003e apply a variant of the attack that makes MuSig1 insecure if the nonce\n\u003e commitment\n\u003e round was skipped or if the message isn't determined before sending the\n\u003e nonce.\n\u003e Here's how a malicious client would do that:\n\u003e\n\u003e - Obtain K R-values R1[0], ..., R1[K-1] from the server\n\u003e - Let\n\u003e      R[i] := R1[i] + R2[i] for all i \u003c= K-1\n\u003e      R[K] := R1[0] + ... + R1[K-1]\n\u003e      c[i] := H(X, R[i], m[i]) for all i \u003c= K.\n\u003e    Using Wagner's algorithm, choose R2[0], ..., R2[K-1] such that\n\u003e      c[0] + ... + c[K-1] = c[K].\n\u003e - Send c[0], ..., c[K-1] to the server to obtain s[0], ..., s[K-1].\n\u003e - Let\n\u003e      s[K] = s[0] + ... + s[K-1].\n\u003e    Then (s[K], R[K]) is a valid signature from the server, since\n\u003e      s[K]*G = R[K] + c[K]*a1*X1,\n\u003e    which the client can complete to a signature for public key X.\n\u003e\n\u003e What may work in your case is the following scheme:\n\u003e - Client sends commitment to the public key X2, nonce R2 and message m to\n\u003e the\n\u003e    server.\n\u003e - Server replies with nonce R1 = k1*G\n\u003e - Client sends c to the server and proves in zero knowledge that c =\n\u003e    SHA256(X1 + X2, R1 + R2, m).\n\u003e - Server replies with s1 = k1 + c*x1\n\u003e\n\u003e However, this is just some quick intuition and I'm not sure if this\n\u003e actually\n\u003e works, but maybe worth exploring.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230724/fc27bc0b/attachment-0001.html\u003e"}