Should an even Y coordinate be enforced after every key-tweak operation, or only at the end?

Question

This is a very niche question regarding BIP340 and key tweaking with even-only public keys.

I feel my question may be a matter of opinion, since there doesn't appear to be an accepted right / wrong way to do things.

Key Tweaking

Let's say that you want to apply a series of tweaks to a secret key, and the returned key needs to have an even Y coordinate.

You have two operations available:

• [tweak] secret key (sec * tweak % N)
• [negate?] secret key (if pub(sec) == odd then sec * (N - 1))

You can apply the tweaks in two possible ways:

• 1. [tweak], [tweak], [negate?]
• 2. [tweak], [negate?], [tweak], [negate]

Both solutions are valid, and will produce the desired key. However, neither solution is compatible with the other, so all parties must agree on which method to use.

So what is the accepted solution here? The first solution requires less operations, but the second solution may also have some benefit?

The concept of even-only public keys is relatively new, so I'm not sure what the clear consensus is here.

Any feedback would be greatly appreciated!

Answer 1

This is a question for designers of cryptographic schemes/protocols which use BIP340 signatures as a building block. If you are only implementing an existing scheme, then hopefully these choices are already made for you, and deviating may even mean the introduction of incompatibilities.

Given that, I do agree this is mostly a matter of opinion, as it's probably possible to work constructions work both ways.

That said, my personal view is that in nontrivial settings, switching to x-only keys (= enforcing even Y coordinate) is better done as late as possible. Roughly, I feel that we now have 3 "levels" of keys in the design space, where each is smaller than the previous one, and contains a strict subset of the information, but loses and/or complicates certain functionality:

• BIP32 extended public keys (full X/Y coordinate + chaincode), which permit derivation of child keys
• full public keys (just X/Y coordinate), which permit BIP-341 style tweaking easily, and ECDSA signatures.
• X-only keys (just X coordinate), which permit BIP-340 Schnorr signatures and ECDH key agreement.

Taproot (BIP-341) outputs, internal keys, and BIP-342 script keys are necessarily x-only, a choice that minimizes on-chain size but introduces some complexity. Most other places where keys are communicated (e.g. as part of protocols whose eventual goal is an on-chain key/signature) do not have such a strong need to minimize data size, and it is thus not necessarily the right trade-off for them.

Further, in multi-party signing protocols such as MuSig2, key negation steps further in the pipeline (in order to enforce even Y coordinates there) can complicate signing, by introducing conditional negations based on a combined key. The more even-Y requirements exist along the way, the more such negations at signing time may be necessary.

Of course, there likely exist scenarios where there is little or no difference in complexity between the two approaches, and in that case it may be pragmatic to stick with more X-only steps if it means code/constructions for dealing with those can be reused.

Answer 2

I think that the correct way to store a key pair is to keep complete information about it. There isn't any need to negate if a correct key is given.

A key is manipulated/altered/modified/composited/tweaked independently of the operation of negation described in the BIP340-342.

I think that the quote ("may need to") supports that position:

Note that because tweaks are applied to 32-byte public keys, taproot_tweak_seckey may need to negate the secret key before applying the tweak.

https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki

In other words, above mentioned negating should not be mixed with other operations. Also, the negation is not necessary when you have complete information about keys being used. In short, never negate unless you don't know which one out of two keys is a correct/actual one.