Re: [bitcoin-dev] MuSig2 BIP

From: AdamISZ <AdamISZ@protonmail•com>
To: Jonas Nick <jonasdnick@gmail•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] MuSig2 BIP
Date: Sun, 22 May 2022 22:26:08 +0000	[thread overview]
Message-ID: <yitwgERAsaofLM5dheUZUYyFp0ncU8xyN98xTym3MkCxTch83DkweZN5JYyovVcfxA2Mo7DjTbv1Iku3wBApYiPG_cMwznTytKFpcjYa1O0=@protonmail.com> (raw)
In-Reply-To: <46175970-d2ab-a58e-7010-f29820849604@gmail.com>

Jonas,

Many thanks for getting the BIP draft out. Particularly appreciate the reference code!

I have a question about identical pubkeys (including how it relates to MuSig2* optimization):

What is the purpose of allowing this? Isn't it always the case that N equal keys combined with M non-equal keys is logically equivalent to 1+M keys? It non trivially complicates certain aspects of the algorithm to allow it and I guess I must be missing something in my previous statement because, otherwise, isn't it pointless (and pretty unwise, considering how likely it is to come from an error)? The whole 'second key' thing in MuSig2 is a sorty of icky side effect.

A valid point about this is already made in the BIP and enunciated clearly and in detail: that MuSig2 is designed to discover lying at the partial sig verify stage, so it's not really that I'm saying that what's in the BIP is logically or mathematically wrong; it just seems unwise and needlessly complex. The case of 2 keys being identical does not imply an attacker; it is far more likely to be a busted implementation by counterparties where they're accidentally using P1, P1 instead of their intended P1, P2.

I suppose the key word is 'needlessly' - is there a need for this that I'm overlooking?

Cheers,
waxwing/AdamISZ

Sent with ProtonMail secure email.
------- Original Message -------
On Tuesday, April 5th, 2022 at 17:57, Jonas Nick via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:

> Tim Ruffing, Elliott Jin, and I are working on a MuSig2 BIP that we would like
> to propose to the community for discussion. The BIP is compatible with BIP340
> public keys and signatures. It supports tweaking, which allows deriving BIP32
> child keys from aggregate keys and creating BIP341 Taproot outputs with key and
> script paths. You can find the BIP draft at:
> https://github.com/jonasnick/bips/blob/musig2/bip-musig2.mediawiki
>
> The draft is in a state where it should be possible to write an implementation
> based on the BIP that passes the basic test vectors (as, e.g., demonstrated by
> [0]). The draft BIP also contains a reference implementation in python. Please
> be aware that this is only a draft and that it may still be necessary to make
> small tweaks to the algorithms and test vectors.
>
> [0] https://github.com/btcsuite/btcd/pull/1820
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev