What would happen if you tweaked a public key with an odd y-coordinate?

Question

From BIP341 this example code shows how you can tweak an x-only pubkey:

def taproot_tweak_pubkey(pubkey, h):
    t = int_from_bytes(tagged_hash("TapTweak", pubkey + h))
    if t >= SECP256K1_ORDER:
        raise ValueError
    Q = point_add(lift_x(int_from_bytes(pubkey)), point_mul(G, t))
    return 0 if has_even_y(Q) else 1, bytes_from_int(x(Q))

(The function lift_x will returns a point (x, y) with an even y-coordinate.)

My question is: what would happen if you had a secret key that produced a pubkey with an odd y-coordinate, e.g. 03af455f4989d122e9185f8c351dbaecd13adca3eef8a9d38ef8ffed6867e342e3, but then simply ignore the first byte (03) and passed in af455f4989d122e9185f8c351dbaecd13adca3eef8a9d38ef8ffed6867e342e3 to the taproot_tweak_pubkey function and sent funds to the resulting tweaked pubkey?

Would you still be able to spend the output via key path and script path? And if so, how?

And a similar question: what would happen if instead you actually did the point addition using the public key with an odd y-coordinate, e.g.:

Q = point_add(P_with_odd_y, point_mul(G, t))

Would the output still be spendable (from either key path or script path) in this case?

Michael Folkson · Accepted Answer · 2022-10-10T14:51:17.053

My question is: what would happen if you had a secret key that produced a pubkey with an odd y-coordinate, e.g. 03af455f4989d122e9185f8c351dbaecd13adca3eef8a9d38ef8ffed6867e342e3, but then simply ignore the first byte (03) and passed in af455f4989d122e9185f8c351dbaecd13adca3eef8a9d38ef8ffed6867e342e3 to the taproot_tweak_pubkey function and sent funds to the resulting tweaked pubkey?

BIP340 is a specification of Schnorr public keys and Schnorr signatures for Bitcoin. Every valid x coordinate on the secp256k1 curve has two possible y coordinates and so every secret key produces two possible Schnorr pubkeys (two possible y coordinates). BIP340 chooses the y coordinate that is even as the valid BIP340 pubkey with the y coordinate that is odd defined as an invalid BIP340 pubkey. This was a design choice when BIP340 was finalized but now that design choice is active on the network you have to follow it to generate valid BIP340 signatures that will pass the BIP340 signature verification algorithm. Every full node running Taproot rules will only accept Schnorr signatures that follow the BIP340 rules. If you don't follow them you will produce invalid BIP340 signatures and you won't be able to spend from that output.

You could in theory locally store the x coordinate or the odd y coordinate and still be able to recover from it but anything that goes onchain (pubkey encoded in UTXO, future attempt to spend from that UTXO) has to follow the BIP340 rules.

Would you still be able to spend the output via key path and script path? And if so, how?

No if you have to produce a signature and you don't follow the prerequisites of the BIP340 signature algorithm you won't produce a valid BIP340 signature.

And a similar question: what would happen if instead you actually did the point addition using the public key with an odd y-coordinate, e.g.:

Q = point_add(P_with_odd_y, point_mul(G, t)) Would the output still be spendable (from either key path or script path) in this case?

Same answer. If you don't perform the Taproot tweak as the BIP341 rules specify and the BIP341 verification rules expect then you will fail any future attempt to spend from that output. These are all essentially consensus rules that need to be followed and enforced to prevent network splits.

What would happen if you tweaked a public key with an odd y-coordinate?

1 Answers1