From: Jonas Nick <jonasdnick@gmail.com>
Message-ID: <d1db8481-140b-a0b4-8c24-4486f8a1cab6@gmail.com>
Date: Wed, 26 Jul 2023 14:59:42 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: moonsettler <moonsettler@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <CAJvkSsc_rKneeVrLkTqXJDKcr+VQNBHVJyXVe=7PkkTZ+SruFQ@mail.gmail.com>
 <b770096c-e8c4-70f7-8cd7-d74c27181413@gmail.com>
 <O3LTbUbjNa3SLUfJzSKDNLBCIhED_6rdOcmgLpYB9byX6HBVg3BMu3hrvY37fH4SGL8th8oJaVV6_ogl_ZOA0qTXgENq8xqQNSRB-VsHem4=@protonmail.com>
In-Reply-To: <O3LTbUbjNa3SLUfJzSKDNLBCIhED_6rdOcmgLpYB9byX6HBVg3BMu3hrvY37fH4SGL8th8oJaVV6_ogl_ZOA0qTXgENq8xqQNSRB-VsHem4=@protonmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] Blinded 2-party Musig2
Precedence: list

While this may solve blinding, I don't see how it solves the problem that the
client can forge signatures because the client is in control of challenge e'.
This is not special to MuSig(2), but is also the reason why original blind
Schnorr signatures are insecure (as demonstrated in David Wagner's "A
Generalized Birthday Problem" paper).

For some more recent work on blind Schnorr signatures, see:
- https://eprint.iacr.org/2019/877.pdf Blind Schnorr Signatures and Signed
   ElGamal Encryption in the Algebraic Group Mode
- https://eprint.iacr.org/2020/1071.pdf On Pairing-Free Blind Signature Schemes
   in the Algebraic Group Model

In particular, the first paper proposes a less-efficient variant of blind
Schnorr signatures that is secure under concurrent signing if the "mROS" problem
is hard (which is imho plausible). Another potential approach is using
commitments and a ZKP as I mentioned earlier in this thread. This scheme is
"folklore", in the sense that it is being discussed from time to time but isn't
specified and does not have a security proof as far as I am aware.