So why verify for parity right here, why not simply be content material to verify for identical X-coord?

That’s not potential in batch validation.

In batch validation, one is given plenty of equations on factors of an elliptic curve, after which checks concurrently whether or not all of them maintain, sooner than checking all of them individually. If not less than considered one of them shouldn’t be legitimate, batch validation simply returns failure, with out indicating which one failed.

This holds the potential of a major validation speedup in Bitcoin, as a result of in blocks we do not care about which transactions/inputs are legitimate or not, simply whether or not all of them are, and blocks could have hundreds of such checks.

However the essential level is that this solely works for elliptic curve equations, i.e., equations of the shape a₁P₁ + a₂P₂ + … + a_nP_n = b₁Q₁ + b₂Q₂ + … + b_mQ_m, for scalars a_i, b_i and factors P_i, Q_i.

If we might drop the parity verify from BIP341, the equation can be:

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

There may be nothing insecure about simply having this. As you level out, the verifier can simply run the equation precisely just like the signer. Nonetheless, it isn’t an elliptic curve equation, and thus it can’t be carried out in a batch validation setting. That’s as a result of it actually corresponds to 2 potential elliptic curve equations:

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

To be usable in a batch validation setting, the verifier should know which of those equations is the one to decide on. They cannot simply guess, as a result of if there are okay tweaks to confirm, there are 2^okay potential mixtures, so batch validation would wish to run that many instances, undoing any velocity benefits batch validation could achieve.

The parity bit is precisely the knowledge a batch verifier wants to pick between these two equations. So as phrases, given a parity bit, each tweak validation turns right into a single elliptic curve equation.

In fact, you possibly can wonder if it’s essential that non-batch-validating nodes care concerning the parity bit. Could not they simply ignore it? Sadly, that may imply a possible consensus failure (chain break up) between batch validating nodes and non-batch validating nodes in case an in any other case legitimate tweak is current within the chain with incorrect parity bit. Regular nodes would settle for it, however batch-validating ones wouldn’t.

So in brief: the parity verify is important to accomodate the chance of batch validators on the community. Observe that batch validation shouldn’t be at present carried out; its advantages will develop nonetheless as Taproot will get extra adoption on chain.

However I can’t discover out why. I can’t see whenever you would have a scenario the place you’d be verifying a batch of Signatures “committing” to the taproot_tweak_pubkey. Don’t you solely try this within the P2TR-Key-Path spend? And in that case, the parity shouldn’t be checked (there isn’t even a Management Block).

Batch validation is not nearly signatures. BIP341 introduces a number of varieties of elliptic curve primarily based validation guidelines to Bitcoin:

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

In idea, all three of those could be batched collectively for an entire block, and checked directly.