Key path spend

A Taproot output can be emptied by signing for its key or by revealing a committed script, and the key route is the quiet one. BIP-341 fixes that witness at exactly one element, a 64-byte Schnorr signature under the default sighash, which makes the whole input 230 weight units, or 57.5 vbytes. For a holder, a shared vault and a solo payment then look the same on chain.

How it works

A key path spend signs for the output key, which is nobody's chosen key: BIP-341 builds it as Q = P + int(t)G, where P is the internal public key and t is a tagged hash of P together with the merkle root of the script tree.

Signing therefore means applying that same shift to the private side. The reference routine negates the secret key first when the internal point has an odd y coordinate, because taproot tweaks are applied to 32-byte x-only keys, then adds t modulo the order of the curve. The result signs under BIP-340 and goes onto the witness stack on its own.

Validation is a counting test before it is a cryptographic one. A node reads the 32 bytes of the witness program, fails at once if the witness stack is empty, and strips the last element as the annex when there are two or more elements and that element begins with 0x50. If exactly one element remains, the spend is a key path spend, and that element has to verify as a BIP-340 signature against the output key. Nothing in that procedure tells the node whether a script tree was ever committed to.

The signature is 64 bytes when SIGHASH_DEFAULT, value 0x00, is implied, which covers the whole transaction. It runs to 65 bytes when a different sighash byte is appended, and a 65-byte signature carrying 0x00 in that last position is rejected deliberately: permitting it would let a miner or any relaying node pad a 64-byte signature out to 65, changing the wtxid and the fee rate the sender intended.

What the signature covers is at most 206 bytes of message. It commits to the transaction version and locktime, to hashes of every input outpoint, amount, previous scriptPubKey and sequence number, and to the outputs.

The size arithmetic falls out of that. Under BIP-141, transaction weight is base size times three plus total size, and virtual size is that weight divided by four, rounded up for a whole transaction. A Taproot input contributes 41 base bytes (a 36-byte outpoint, one length byte for an empty scriptSig, a four-byte sequence) and 66 witness bytes (a stack count, a length prefix, the signature), giving 41 times 3 plus 107, or 230 weight units, and so 57.5 vbytes.

One recommendation in BIP-341 catches wallet authors out. An output with no scripts at all should still commit to a tweak, computed as a tagged hash of the internal key by itself, rather than publishing the internal key untouched. The specification spells out why: where two parties add their keys into a shared output key, one of them can quietly fold in a tweak hiding a script path spendable by them alone, and the other has no way to notice.

Why this matters when you buy bitcoin

Taproot's signature message is the reason a hardware wallet can work out your fee without trusting the computer it is plugged into.

Under BIP-143, the SegWit version 0 rules, the message committed to the amount being spent by the signed input and nothing more. A device signing one input of a three-input transaction had to be handed the other two amounts and could not check them, which is the opening a compromised host uses to have you sign away far more in fees than the screen showed. BIP-341 commits to the amounts of every input the transaction spends, and to all of their previous scriptPubKeys, so a signer can total them itself. That upgrade covers script path spends too, but the key path is where most owners of the devices in our 41 wallet reviews will meet it.

Your wallet has to be able to derive the keys before any of it applies, and across those reviews the picture is uneven. KeepKey added Taproot output support in firmware 7.10.0 in February 2025. MetaMask's own announcement still lists Taproot as coming later, so it cannot give you a bc1p address to receive at, whatever the rest of its bitcoin support does.

Fees tilt toward the key path by a small margin per input, which accumulates in the direction most readers buy. The signed P2WPKH input in BIP-143's own test vector carries a 71-byte signature and a 33-byte key, 107 witness bytes once the stack count and the length prefixes are counted, which comes to 271 weight units, or 67.75 vbytes. A key path input saves 10.25 vbytes against that, so a saver who has stacked 30 separate small purchases and later consolidates them shaves about 307 vbytes off that one transaction.

Be clear about what the privacy actually buys. Hiding your spending policy is not hiding your history: if the coins came from one of the 63 exchanges we review, that platform already holds your identity documents and the withdrawal address, and no signature format touches that. What stays hidden is whether the coin was guarded by one key or by a quorum with a lawyer's recovery branch, and that second fact is the one that makes an address worth targeting.

Walking through taproot_sign_key

taproot_sign_key is the reference routine BIP-341 publishes for producing this exact witness, and the whole of it is nine lines of Python.

It takes a script tree, the internal secret key, a sighash type and the auxiliary randomness BIP-340 asks for. When the script tree is empty it sets the tweak input to an empty byte string; otherwise that input is the merkle root returned by the tree helper. It tweaks the internal secret key with that value, signs the sighash, appends the hash type byte only when the type is not zero, and returns a list holding one item. That item is the whole witness.

Two details repay attention. The empty branch is not the untweaked case it looks like, because feeding an empty byte string in leaves the tweak as the tagged hash of the internal key on its own, which is exactly the unspendable commitment the specification recommends for an output with no scripts. And the randomness argument belongs to BIP-340 rather than to Taproot: once the key has been tweaked, the result is an ordinary Schnorr signature, which is why key path spends need no special handling to be verified in batches.

Key path spend vs P2TR

P2TR is the output type, and a key path spend is one of the two ways to empty one. A coin stays a P2TR coin no matter which route later drains it. The distinction matters when someone tells you Taproot addresses are private: receiving to one publishes a 32-byte key and nothing else either way, while the privacy people mean arrives at the moment of spending, and only if the key route is the one taken.

Key path spend vs MuSig2

MuSig2 is one way to produce the signature a key path spend needs, and not a requirement of one. A single owner signing with a single key makes a key path spend every time they pay, with no aggregation protocol in sight. The two get conflated because aggregation is the interesting case: MuSig2 lets several parties reach one key and one signature, so their settlement takes the same route and the same 57.5 vbytes as somebody paying for lunch. It runs the other way too, since an aggregate key can sit inside a script leaf, where spending it is a script path spend that happens to use MuSig2.