Taproot Output Key

The Taproot output key, denoted Q in BIP 341, is the 32-byte X-only public key that actually appears in a Pay-to-Taproot (P2TR) scriptPubKey, following the witness version byte OP_1. It is derived by tweaking the internal key P with a commitment to the output's script tree: Q = P + t·G, where t = hashTapTweak(P || merkle_root) and G is the secp256k1 generator. Everything an outside observer can learn about a Taproot output's spending conditions is contained in this single key — which is to say, nothing.

Indistinguishability and privacy

Because Q looks like any other public key, an on-chain observer cannot determine whether the output is a simple single-signature wallet, a corporate multisig with a dozen fallback clauses, or a Lightning channel. A key-path spend reveals nothing beyond one Schnorr signature; a script-path spend reveals only the one script branch actually used plus a merkle inclusion proof, never the sibling branches. This collapses many distinct contract types into one uniform output format, and the privacy is collective: every wallet that uses P2TR for ordinary payments enlarges the crowd that complex contracts hide inside. Even an output with no scripts at all commits to that fact — BIP 341 recommends tweaking by hash(P) with an empty tree rather than using an untweaked key, so no observer can distinguish "no scripts" from "scripts I haven't seen."

X-only keys and parity

Q is serialized as 32 bytes — only the X coordinate. Every X coordinate corresponds to two curve points (even and odd Y), and BIP 340 resolves the ambiguity by convention: the key is implicitly the point with even Y. The discarded parity information resurfaces in exactly one place: during a script-path spend, one bit of the control block records the parity of Q so verifiers can reconstruct the full point when checking the commitment. This 32-byte serialization saves a byte per key versus legacy compressed keys and simplifies signature verification.

Verification

For a key-path spend, validators check a BIP 340 Schnorr signature directly against Q — one signature, one key, no script execution at all. For a script-path spend, validators take the revealed leaf script, walk the merkle path supplied in the control block to recompute the root, re-derive t from the internal key and that root, and confirm that P + t·G matches the committed Q (X coordinate plus the recorded parity bit). Only if this reconstruction succeeds is the script actually executed. The elegance is that the output key does double duty: it is simultaneously a working public key and a cryptographic commitment, with neither role visible in the other.

For wallet builders, Q is what appears in a bech32m address (prefix bc1p), and address verification on a hardware signer is ultimately a check that the device derives the same Q from the same internal key and tree. The output key is the public face of the Taproot tweak; its ingredients are the Taproot internal key and the Taproot merkle path that proves any revealed script belongs to the tree.

What Q means for verification culture

The output key also carries a practical lesson in verification. Because Q commits to both a key and a tree, receiving to a Taproot address means trusting that whoever derived it included the scripts you expect — no more, no fewer. A malicious coordinator handing you an address could embed an extra spending branch you never agreed to, and the address would look perfectly normal. The defense is standard sovereign practice scaled to Taproot: derive addresses yourself from a descriptor you hold, verify them independently on your hardware signer's screen, and in multiparty settings insist that every participant reconstructs Q from the agreed components rather than accepting a finished address on faith. "Don't trust, verify" applies bit-for-bit to the 32 bytes that decide who can spend.