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

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

That’s not attainable in batch validation.

In batch validation, one is given various 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 no less than one in all 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’d drop the parity examine from BIP341, the equation could be:

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

There’s nothing insecure about simply having this. As you level out, the verifier can simply run the equation precisely just like the signer. Nonetheless, it’s not 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 attainable combos, so batch validation would want to run that many instances, undoing any pace benefits batch validation could acquire.

The parity bit is strictly 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.

After all, you possibly can wonder if it’s obligatory that non-batch-validating nodes care concerning the parity bit. Could not they simply ignore it? Sadly, that might 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 briefly: the parity examine is important to accomodate the risk of batch validators on the community. Word 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 not discover out why. I can not see if 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 concept, all three of those will be batched collectively for a complete block, and checked directly.