Date: Sun, 22 May 2022 22:26:08 +0000
To: Jonas Nick <jonasdnick@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: AdamISZ <AdamISZ@protonmail.com>
Reply-To: AdamISZ <AdamISZ@protonmail.com>
Message-ID: <yitwgERAsaofLM5dheUZUYyFp0ncU8xyN98xTym3MkCxTch83DkweZN5JYyovVcfxA2Mo7DjTbv1Iku3wBApYiPG_cMwznTytKFpcjYa1O0=@protonmail.com>
In-Reply-To: <46175970-d2ab-a58e-7010-f29820849604@gmail.com>
References: <46175970-d2ab-a58e-7010-f29820849604@gmail.com>
Feedback-ID: 11565511:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] MuSig2 BIP
Precedence: list

Jonas,

Many thanks for getting the BIP draft out. Particularly appreciate the refe=
rence code!

I have a question about identical pubkeys (including how it relates to MuSi=
g2* 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? I=
t non trivially complicates certain aspects of the algorithm to allow it an=
d I guess I must be missing something in my previous statement because, oth=
erwise, 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 com=
plex. 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-d=
ev@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 BI=
P340
> public keys and signatures. It supports tweaking, which allows deriving B=
IP32
> child keys from aggregate keys and creating BIP341 Taproot outputs with k=
ey 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 implement=
ation
> based on the BIP that passes the basic test vectors (as, e.g., demonstrat=
ed by
> [0]). The draft BIP also contains a reference implementation in python. P=
lease
> 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