Definition
An x-only public key is the 32-byte key format introduced by BIP340 for Schnorr signatures and used throughout Taproot. Instead of recording both coordinates of a curve point, or the usual 33-byte compressed form with a leading sign byte, it stores only the x-coordinate and drops the prefix entirely. This trims one byte off every key relative to the 33-byte compressed encoding — a small saving that compounds across every output and every spend on the network.
The even-Y convention
Each valid x-coordinate corresponds to two points on the curve, one with an even y-coordinate and one with an odd y. BIP340 resolves the ambiguity with a simple rule: the y-coordinate is always taken to be even. An x-only public key is therefore equivalent to a compressed public key prefixed by the byte 0x02. Choosing even-Y gives the greatest compatibility with existing key-generation systems, since standard compressed formats already signal y-coordinate parity, so wallets can adopt the shorter encoding without changing how they derive keys. The convention is a deliberate design choice to reuse decades of existing tooling rather than reinvent it.
Reconstructing the point
Verifiers rebuild the full point using the lift_x function: it checks that the x value is below the field prime, computes the corresponding y on the curve, returns the point whose y is even, and fails if no such point exists. This lets a verifier recover everything needed to check a signature from just 32 bytes, with no loss of security — the discarded parity bit carries no secret, only a convention. Because every node performs this same deterministic reconstruction, the shorter encoding is unambiguous across the entire network.
How Taproot uses it
An x-only key is not just a raw public key in Taproot; it is the tweaked output key that commits to both a spending key and an optional script tree. That single 32-byte value on-chain can therefore stand in for an entire policy. When someone spends via the key path, they simply sign for that output key, and observers see nothing of the scripts that might have been hiding behind it. The compact encoding and the commitment structure work together to make the common case cheap and private.
Why sovereign users benefit
Smaller keys mean smaller, cheaper transactions. Because Taproot spends carry x-only keys in the witness, they cost fewer virtual bytes, and in a busy mempool fewer bytes translate directly into lower fees. The format also improves privacy: key-path Taproot spends look identical on-chain whether they hide a single signer or a complex multisignature policy, so an x-only key reveals nothing about the conditions behind it. Fewer bytes and less leaked structure is exactly the kind of quiet efficiency that rewards people who hold their own keys.
A subtle but important consequence of the even-Y rule is that signing implementations must be written to respect it. When a wallet works with a key whose underlying point has an odd y-coordinate, the BIP340 signing process effectively negates the key so that the public value presented on-chain is always the even-Y form. Getting this wrong produces signatures that fail to verify, a common early pitfall when implementing Taproot support from scratch. For an ordinary user none of this is visible: a compliant wallet handles the parity bookkeeping internally, and the only thing they experience is a shorter address and a slightly cheaper spend. The detail is a good reminder that Bitcoin's efficiency gains are usually paid for by careful, invisible engineering in the software that safeguards keys, which is one more reason to run well-reviewed, open-source wallet software.
The format depends on the underlying secp256k1 structure and the fact that the curve lives over a prime finite field. It is the key format that Schnorr batch verification operates on, and the encoding every Taproot output ultimately commits to.
In Simple Terms
An x-only public key is the 32-byte key format introduced by BIP340 for Schnorr signatures and used throughout Taproot. Instead of recording both coordinates of…
