Musig2 - Problem with verification using x-only public keys

[Loopite]

Hello,

In the current implementation of libsecp256k1, the function secp256k1_musig_pubkey_agg computes an aggregate public key specifically from an array of const secp256k1_pubkey *. This means users must be aware of the compression of public keys when signing and verifying; however, signing is not really the most difficult part. The question is: how can a verifier compute the same aggregate public key as the signer without knowledge of the compression of public keys?

Context for the question: In Taproot, users work with x-only public keys. If the owner of a group of x-only public keys signs with MuSig2 and does not send any information about the compression of each public key, it will not be possible to verify their signature correctly since the aggregate public key will differ. Am I correct?

Thank you for your answers.

[sipa]

If by verifier, you mean full nodes enforcing the consensus rules... they don't care, as they only ever see the aggregate public key, and want a signature that is a valid BIP340 signature for that. They don't even know it's a MuSig2 aggregate.

If by verifier you mean another party, who is interested in verifying that individual participants signed, they will need to know the public keys of the participants and recompute the aggregate themselves before verifying a signature against it. Those public keys must be the same as the ones used at signing time. x-only keys can be converted to full public keys by assuming they are even. It suffices if signers and verifiers use the same convention.

[Loopite]

Thank you for the quick response,

If by verifier you mean another party, who is interested in verifying that individual participants signed, they will need to know the public keys of the participants and recompute the aggregate themselves before verifying a signature against it. Those public keys must be the same as the ones used at signing time.

Yes, won't this be also the case in the implentation of Musig2 in Bitcoin? Because each x-only is linked to 2 private keys and it seems the protocol doesn't create the private key where the y coord of its public key is even isn't it (i.e. we can have a private key where the y coord of the public key is odd)? If so, the computation of the aggregate public key when nodes will verify the transaction will differ from the signer's one.

[sipa]

x-only pubkeys are only ever signed for using the private key corresponding to the equivalent even full public key (the BIP340 signing algorithm will negate the private key internally if need be for this).

MuSig2 aggregation/signing needs to do the same thing if you'd be working with x-only input keys: treat them as even public keys for aggregation purposes, and conditionally negate the private key at signing time to account for that.

But again, this isn't normally needed if you're talking about normal transaction signing. The verifier in this case doesn't know or care what the individual public keys were, or even that MuSig2 was used at all.

[Loopite]

Damn, negating the private key with secp256k1_ec_seckey_negate solves the problem, I’d forgotten about that one!
Just to be clear, when we know it’s a MuSig2 transaction, we’ll have to compute the aggregate public key by prepending 0x02 to each public key to indicate that the y coordinate is even, won’t we? Then we’ll get the x-only aggregate public key and can verify the signature with secp256k1_schnorrsig_verify.

[real-or-random]

The "official" way to use BIP327 (MuSig) key aggregation assumes that the individual public keys are "plain" (33 byte) public keys. That is reflected in the API.

Now, if you want to use individual keys, which are "x-only" (32 bytes), the question is: why are you doing it that way? The normal use case is to derive the individual keys via BIP32, which produces plain public keys (instead of x-only public keys).

[Loopite]

In the BIP327 key aggregation assumes that the individual pubkeys are plain (with the y compression flag).

Yes.

I'm currently using Musig2 where pubkeys aren't plain in a new project, and I believe it's the direction Bitcoin has to move toward. In my opinion, using plain (compressed) public keys in MuSig2 seems unnecessary. If an attacker has a private key that corresponds to the same x-only public key as a legitimate signer, they can simply negate the private key and still produce a valid signature (possibly requiring the cooperation of other participants, except in case of solo signing). Also, plain compressed public keys are slightly larger than x-only keys, which makes x-only preferable in some contexts.

Let me know if I'm mistaken, but as I understand it, MuSig2 is more secure than basic Schnorr key aggregation. MuSig2 can even be used by a single signer to aggregate multiple keys they control into one public key and produce a single signature, unlocking then all his inputs at once (that's the goal we have to reach in Bitcoin I think). This is exactly the kind of functionality I'm looking for.

The normal use case is to derive the individual keys via BIP32, which produces plain public keys (instead of x-only public keys).

That's true, but it's easy to accidentally omit or mishandle the compression flag. It could be slightly better if you're unlocking a PKH input where the pubkey was a x-only in the SHA256 hasher (I think in bitcoin we must use the compression flag in the hasher). I'm talking about a different project that would use that.
Of course, x-only isn't currently the standard output of BIP32, but it could be in the future.

[sipa]

I believe it's the direction Bitcoin has to move toward.

I disagree.

Also, plain compressed public keys are slightly larger than x-only keys, which makes x-only preferable in some contexts.

Unless you plan to put these public key on chain (and given that you use MuSig2, I'm assuming only an aggregate, if any, will end up on chain), I cannot imagine many use cases where a 1 byte difference would matter. My suggestion would be to not do that, it's going to make your life harder.

MuSig2 is more secure than basic Schnorr key aggregation.

What does "basic Schnorr key aggregation" mean? Key aggregation is a concept, not a specific protocol. If by this you mean "just sum the public keys, and sum the corresponding nonces", then yes, MuSig2 isn't just "more secure"; what you're talking about is likely completely broken.

produce a single signature, unlocking then all his inputs at once (that's the goal we have to reach in Bitcoin I think).

That is talking about a signature-aggregation scheme, not a key aggregation scheme like Musig2. One can be built on top of MuSig2, but there are pitfalls, and recently a scheme called DahLIAS was proposed to enable this. The integration of a feature like this is in Bitcoin called CISA (cross-input signature aggregation). But note that in this case, key aggregation isn't relevant, as the verifier has access to all individual public keys (each transaction output spent will have their own).

That's true, but it's easy to accidentally omit or mishandle the compression flag.

Sure, but you can also easily get the sign-flipping wrong to correct for the fact that you don't have a sign bit.

My view is really that we have 3 "levels" of public keys in Bitcoin now:

• BIP32 keys (X coordinate + Y parity + chaincode), which allow signing, aggregating, and deriving new keys.
• Full keys (X coordinate + Y parity), which allow signing, aggregation, but not deriving new keys.
• X-only keys (X coordinate), which allow signing, but not aggregation or deriving new keys.

At any point when you don't need to derive anymore (i.e., you're at a leaf of a BIP32 derivation tree), you can drop the chaincode and go to a full key. At any point when you don't need to aggregate anymore, you can drop the Y parity bit. If size isn't a concern, you can just keep everything.

And yes, of course you can go backward too. You can go back from full to BIP32 by adding a synthetic chainciode. And you can go back from X-only to full by assuming an even Y parity. But doing so makes protocols messy and breaks abstraction layers.