taproot – Why is it necessary to reveal a bit in a script path spend and check that it matches the parity of the Y coordinate of Q?

So why check for parity here, why not just be content to check for same X-coord?

That is not possible in batch validation.

In batch validation, one is given a number of equations on points of an elliptic curve, and then checks simultaneously whether all of them hold, faster than checking them all individually. If at least one of them is not valid, batch validation just returns failure, without indicating which one failed.

This holds the potential of a significant validation speedup in Bitcoin, because in blocks we don’t care about which transactions/inputs are valid or not, just whether all of them are, and blocks may have thousands of such checks.

But the crucial point is that this only works for elliptic curve equations, i.e., equations of the form a₁P₁ + a₂P₂ + … + a_nP_n = b₁Q₁ + b₂Q₂ + … + b_mQ_m, for scalars a_i, b_i and points P_i, Q_i.

If we would drop the parity check from BIP341, the equation would be:

• q = x(P + tG), where q is output X coordinate, P is the internal key, and t is the tweak.

There is nothing insecure about just having this. As you point out, the verifier can just run the equation exactly like the signer. However, it is not an elliptic curve equation, and thus it cannot be performed in a batch validation setting. That is because it really corresponds to two potential elliptic curve equations:

• lift_x(q) = P + tG
• lift_x(q) = -(P + tG)

To be usable in a batch validation setting, the verifier must know which of these equations is the one to choose. They can’t just guess, because if there are k tweaks to verify, there are 2^k possible combinations, so batch validation would need to run that many times, undoing any speed advantages batch validation may gain.

The parity bit is exactly the information a batch verifier needs to select between these two equations. In order words, given a parity bit, every tweak validation turns into a single elliptic curve equation.

Of course, you can wonder whether it is necessary that non-batch-validating nodes care about the parity bit. Couldn’t they just ignore it? Unfortunately, that would mean a potential consensus failure (chain split) between batch validating nodes and non-batch validating nodes in case an otherwise valid tweak is present in the chain with incorrect parity bit. Normal nodes would accept it, but batch-validating ones would not.

So in short: the parity check is necessary to accomodate the possibility of batch validators on the network. Note that batch validation is not currently implemented; its benefits will grow however as Taproot gets more adoption on chain.

But I cannot find out why. I cannot see when you would have a situation where you would be verifying a batch of Signatures “committing” to the taproot_tweak_pubkey. Don’t you only do that in the P2TR-Key-Path spend? And in that case, the parity is not checked (there isn’t even a Control Block).

Batch validation isn’t just about signatures. BIP341 introduces several types of elliptic curve based validation rules to Bitcoin:

• Key path spends (BIP340 signatures)
• OP_CHECKSIG operations inside script path spends (also BIP340 signatures).
• Tweak checks in script path spends (what my answer above is about).

In theory, all three of these can be batched together for a whole block, and checked at once.