Taproot Internal Key

The Taproot internal key, written P in BIP 341, is the public key a wallet selects as the foundation of a Taproot (SegWit v1) output before any script commitment is applied. It is not the key that appears on-chain; rather, it is tweaked with a commitment to the output's script tree to produce the published output key. The internal key answers the question "who can spend this cooperatively?" while the script tree answers "what are the fallback rules?" — and Taproot's central trick is folding both answers into one ordinary-looking key.

Role in spending

The internal key defines the key-path spend: when all required parties cooperate, they sign for the tweaked key Q = P + t·G using the tweaked secret p + t, producing one 64-byte Schnorr signature that is indistinguishable from any single-signer payment. This is the cheapest and most private way to spend a Taproot output — no script is revealed, no tree is even shown to exist. In multiparty contexts P is typically an aggregated key from a protocol such as MuSig2, so a group of signers presents a single internal key and their cooperative spend collapses into that same single-signature form. The design philosophy is that the cooperative case should be the common case, and the common case should look like nothing at all.

Disabling the key path

Sometimes the designer wants only script-path spends to be valid — a covenant-style vault, or a contract where no single party should hold a unilateral spending key. Then the internal key is set to a NUMS ("nothing up my sleeve") point: a point constructed so that its discrete logarithm is provably unknown to anyone, making key-path spending impossible rather than merely unlikely. BIP 341 itself suggests a standard construction — lift the X coordinate of a hash of a fixed, published string to a curve point, optionally re-randomised with a commitment to the script data — so that verifiers can be convinced no party could ever forge a key-path signature. Choosing a NUMS point transparently, from public constants, is important: a "random-looking" internal key chosen privately could secretly be a real key someone controls.

Where the internal key reappears

The internal key is not discarded after address derivation. During a script-path spend, its serialized X-coordinate is carried in the control block of the witness, where verifiers use it to recompute the tweak and confirm that the revealed script really was committed inside the output key. Wallets must therefore store the internal key (or be able to re-derive it) for as long as they may need to spend by script path. For descriptor-based wallets, the internal key appears explicitly in the tr(...) descriptor, and hardware signers display it during address verification.

Practical guidance for multisig and self-custody designers: put the expected cooperative quorum on the key path and reserve the tree for exceptions, because every key-path spend strengthens everyone's privacy by enlarging the crowd of identical-looking spends. The commitment arithmetic that binds P to the tree is covered under Taproot tweak, and the on-chain result is the Taproot output key.

Operational notes for key holders

Two practical consequences follow from the internal key's role. First, backup scope: a Taproot output is fully recoverable only if you can reconstruct both the internal key and the script tree, so a descriptor backup — which captures the whole tr(internal_key, {tree}) expression — is the artifact to protect, not merely the seed behind one key. A seed alone recovers key-path funds but cannot even find script-path branches it doesn't know exist. Second, aggregation ceremonies: when P is a MuSig2 aggregate, all cosigners must derive it identically — same key ordering, same aggregation rules — or they will compute different addresses from the same key material. Wallet interoperability here is improving but still worth verifying explicitly: have every signer independently display the address before funds touch it.