Re: [bitcoin-dev] Blinded 2-party Musig2

From: Lloyd Fournier <lloyd.fourn@gmail•com>
To: Erik Aronesty <erik@q32•com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Cc: Tom Trevethan <tom@commerceblock•com>
Subject: Re: [bitcoin-dev] Blinded 2-party Musig2
Date: Thu, 27 Jul 2023 10:54:17 +0800	[thread overview]
Message-ID: <CAH5Bsr2xcp5Hy2DZAWy6PyRMbD9P-8ynmKAGFHgukdLv7VrpQw@mail.gmail.com> (raw)
In-Reply-To: <CAJowKg+wjq8kTOmhEuu--hS2s_FvYEg61z8C_SOvFLsANesc7g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1870 bytes --]

Hello all,

1. No proof of knowledge of each R does *NOT* prevent wagner's attack.
2. In my mind, A generic blind signing service is sufficient for doing
blinded MuSig, Muig2, FROST or whatever without the blind signing service
knowing. You don't need a specialized MuSig2 blind singing service to
extract MuSig2 compatible shares from it. You can just add the MuSig tweak
(and/or BIP32 etc) to their key when you do the blind signing request (this
seemed to be what the OP was suggesting). Making the server have multiple
nonces like in MuSig2 proper doesn't help the server's security at all. I
think the problem is simply reduced to creating a secure blind schnorr
signing service. Jonas mentioned some papers which show how to do that. The
question is mostly about whether you can practically integrate those tricks
into your protocol which might be tricky.

LL

On Thu, 27 Jul 2023 at 08:20, Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> correct.  you cannot select R if it is shipped with a POP
>
> On Wed, Jul 26, 2023, 4:35 PM Tom Trevethan <tom@commerceblock•com> wrote:
>
>> Not 'signing' but 'secret' i.e. the r values (ephemeral keys). Proof of
>> knowledge of the r values used to generate each R used prevents the Wagner
>> attack, no?
>>
>> On Wed, Jul 26, 2023 at 8:59 PM Jonas Nick <jonasdnick@gmail•com> wrote:
>>
>>> None of the attacks mentioned in this thread so far (ZmnSCPxj mentioned
>>> an
>>> attack on the nonces, I mentioned an attack on the challenge c) can be
>>> prevented
>>> by proving knowledge of the signing key (usually known as proof of
>>> possession,
>>> PoP).
>>>
>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 3002 bytes --]