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

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

That’s not potential in batch validation.

In batch validation, one is given numerous 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 every of them will not be legitimate, batch validation simply returns failure, with out indicating which one failed.

This holds the potential of a big 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 test from BIP341, the equation could be:

• q = x(P + tG), the place q is output X coordinate, P is the interior 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’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 can not simply guess, as a result of if there are okay tweaks to confirm, there are 2^okay potential combos, so batch validation would want to run that many instances, undoing any velocity benefits batch validation could acquire.

The parity bit is strictly the data a batch verifier wants to pick out 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’ll be able to wonder if it’s obligatory that non-batch-validating nodes care concerning the parity bit. Could not they only ignore it? Sadly, that will imply a possible consensus failure (chain cut 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 test is important to accomodate the chance of batch validators on the community. Observe that batch validation will not be at the moment applied; 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’ll be verifying a batch of Signatures “committing” to the taproot_tweak_pubkey. Don’t you solely do this within the P2TR-Key-Path spend? And in that case, the parity will not be checked (there isn’t even a Management Block).

Batch validation is not nearly signatures. BIP341 introduces a number of kinds 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 will be batched collectively for a complete block, and checked directly.