Taproot is a deployed Bitcoin consensus upgrade built on Segregated Witness. It did not create a separate chain or replace Bitcoin Script. It introduced pay-to-Taproot outputs, Schnorr signature validation, a new script version called tapscript, and commitment structures that let one output represent a cooperative key path plus one or more hidden script alternatives.
Three BIPs divide the work. BIP 340 specifies Schnorr signatures for secp256k1. BIP 341 defines SegWit version 1 Taproot outputs, output-key commitments, key-path spending, script-path spending, and the Taproot signature message. BIP 342 defines the first tapscript leaf version and its opcode and resource rules.
This guide was reviewed July 25, 2026 against the live deployed BIPs and Bitcoin Core 31.1, tag v31.1, commit 9be056a8a72b624dae9623b2f7bded92c2a21c91, including tagged validation, policy, unit, functional, and wallet-vector evidence. Consensus deployment is established; wallet, exchange, service, threshold-signing, and application support remain implementation-specific and must be checked separately.
BIP 340: the signature scheme
BIP 340 defines 64-byte Schnorr signatures using x-only public keys on secp256k1. The specification includes tagged hashing, deterministic nonce derivation with auxiliary randomness, verification rules, and test vectors.
Schnorr signatures have algebraic properties useful for key aggregation and threshold protocols, but BIP 340 by itself does not define a multisignature coordination protocol. MuSig2, FROST, hardware-wallet workflows, nonce management, and distributed key generation require separate specifications and implementations.
Taproot key-path and tapscript signature checks use BIP 340 signatures under BIP 341 and BIP 342 message rules. Saying “Taproot uses Schnorr” is accurate; saying “Schnorr automatically makes every multisig one signature” is not.
BIP 341: pay-to-Taproot outputs
A pay-to-Taproot, or P2TR, output is a native SegWit version 1 output with a 32-byte witness program. The program represents an x-only output key. P2SH-wrapped version 1 programs and version 1 programs of other lengths are not P2TR under BIP 341.
Let the internal x-only key represent point P. An optional script tree produces Merkle root m; when there is no script tree, the commitment uses an empty byte string instead. The tagged hash TapTweak(bytes(P) || m) produces scalar t, and the output point is Q = P + tG. The construction fails if the tweak is outside the secp256k1 scalar range or the resulting point is invalid. The output commits to x(Q).
This binds the output to the internal key and the exact script-tree root. A verifier learns neither the tree nor whether one exists when the output is created. A later script-path spend reveals only one leaf and the authentication path needed to reconstruct the root.
The internal key is a construction input, not automatically the key a wallet shows to a user. Some protocols use an internal key with known signing control; others use a NUMS-style point designed so no practical key-path spend exists. Those choices have different setup and backup assumptions.
Key-path spending
A key-path spend supplies a Schnorr signature valid for the tweaked output key. No script, control block, or Merkle path is revealed.
This path is useful for a simple single-key output and for cooperative multiparty constructions that can produce one valid signature for an aggregate or threshold key. On chain, those cases can have the same key-path structure.
That similarity can improve privacy, but it is not anonymity. Amounts, timing, input ownership heuristics, address reuse, wallet fingerprints, change behavior, and off-chain information can still reveal relationships. A key-path spend reveals the output type and key-path witness form, even though it does not reveal whether one signer or a coordinated group produced the signature.
Key-path spending is not available merely because multiple parties possess separate keys. They need a correct coordination protocol, nonce handling, signing implementation, backup plan, and compatible wallet or device support.
Script trees and leaves
Each script leaf commits to a leaf version and exact script bytes. BIP 341 defines the tapleaf hash as TapLeaf(leaf_version || compact_size(script_size) || script).
Child hashes are combined with the TapBranch tagged hash after sorting each pair lexicographically. That ordering means a control block does not need separate left-or-right direction bits. Repeating this operation produces the root committed by the TapTweak.
The tree does not need to be balanced. Frequently expected paths can be placed at shallower depth to reduce the Merkle proof revealed when spent. That optimization can also create identifiable shapes, so efficiency and privacy can point in different directions.
Different tree constructions can commit to the same set of spending conditions while producing different roots, output keys, and disclosure sizes. Wallets and protocols must agree on the exact tree, leaf versions, script bytes, internal key, and branch construction before funds are received.
Script-path spending
A script-path spend reveals:
- stack arguments needed by the chosen script;
- the selected script leaf;
- a control block containing the internal key, leaf version and parity information, and the Merkle path.
The validator computes the tapleaf hash, combines it with each 32-byte branch node in lexicographic order, computes the TapTweak, reconstructs the output point, and checks both its x-coordinate and parity against the output and control block. It then applies the rules associated with the revealed leaf version.
Only the selected leaf and its authentication path are revealed. Other leaves remain hidden unless disclosed elsewhere. The path depth, script content, control block, witness shape, and surrounding transaction can still reveal information about the wallet or protocol.
A script-path spend is normally larger than a key-path spend because it publishes the script and proof. Whether it is cheaper than an equivalent P2WSH construction depends on script size, tree depth, witness data, signature structure, and fee conditions.
Control blocks and revealed paths
The control block is commitment-proof data, not an authorization signature. Its length must be 33 + 32m bytes, where m is the number of Merkle nodes and ranges from 0 through 128.
The low bit of its first byte records the output point’s y-coordinate parity; masking that bit yields the leaf version. The next 32 bytes encode the x-only internal key. Each remaining 32-byte element is one node in the authentication path.
A malformed size, invalid internal key, out-of-range tweak, incorrect output-key x-coordinate or parity, or mismatched branch path makes the spend fail. A valid control block proves only that the revealed leaf was committed by the output. It does not prove the script is safe, hidden leaves are harmless, or an unexpected party cannot use the internal key.
BIP 342: tapscript
BIP 342 defines the initial script semantics for Taproot leaves using leaf version 0xc0. Tapscript retains much of Bitcoin Script while changing signature operations and upgrade behavior.
It adds OP_CHECKSIGADD, which supports threshold-style scripts by accumulating successful checks. It makes OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY fail when executed, while those bytes remain ignored in unexecuted branches. It consensus-enforces MINIMALIF.
Tapscript removes the older 10,000-byte script and 201-non-push-opcode limits. If no OP_SUCCESSx is present, the 520-byte stack-element limit and 1,000 combined stack-and-altstack item limit remain, including the initial stack. Script size is bounded indirectly by transaction and block weight.
Its signature budget equals 50 plus the serialized byte size of the input’s full witness, including the compact-size prefix. Each executed signature opcode with a non-empty signature consumes 50 units; if the budget drops below zero, validation fails.
Upgrade paths are separate
Tapscript defines designated OP_SUCCESSx byte values. The script is scanned for them before ordinary parsing, initial-stack checks, pushed-element limits, and execution. Encountering one makes the current script succeed at consensus, even if later bytes would not parse. Standard policy discourages spending an undefined OP_SUCCESSx path.
A future tapleaf version is a different mechanism. After the control block and output commitment are verified, a currently unknown leaf version succeeds without executing its script; Bitcoin Core policy can discourage that upgrade path. Unknown tapscript public-key types form another boundary. These mechanisms are not interchangeable, and none means arbitrary future behavior is already deployed.
Taproot signature hashes
BIP 341 defines a new signature message. Depending on the sighash mode, it commits to the transaction version and locktime; input outpoints, amounts, spent scriptPubKey values, and sequences; outputs; the current input; and annex presence and content.
Committing to spent amounts and scripts helps offline signers understand what they are authorizing when complete previous-output data is supplied. It does not make an untrusted signing device safe by itself.
Taproot introduces SIGHASH_DEFAULT. A 64-byte signature omits the sighash byte and implies this mode, whose output-selection behavior matches SIGHASH_ALL. A 65-byte Taproot signature must append a nonzero defined sighash byte; explicitly appending 0x00 is invalid.
For tapscript signatures, BIP 342 extends the BIP 341 message with the tapleaf hash, key version 0x00, and the opcode position of the last executed OP_CODESEPARATOR, or 0xffffffff if none executed. The tapleaf hash commits to the entire script; the separator position is an additional execution-path commitment.
The annex boundary
If a Taproot witness has at least two elements and the last element begins with byte 0x50, BIP 341 recognizes that element as the annex and removes it before key-path or script-path interpretation.
The annex, or its absence, is committed by the signature message and contributes to transaction weight, but current Taproot consensus rules do not otherwise assign it application meaning. As of Bitcoin Core 31.1, annex-bearing Taproot spends are nonstandard under default policy.
The annex is an upgrade boundary, not a general metadata recommendation. Applications should not assume arbitrary annex data will be relayed, understood, or useful without a separate deployed specification and implementation evidence.
What Taproot improved
Taproot can reduce on-chain disclosure by hiding unused script branches and allowing cooperative outcomes to use a key path. It provides a uniform P2TR output form for key and script commitments. It replaces ECDSA with BIP 340 Schnorr signatures in Taproot validation. It introduces cleaner signature hashing, tapscript, and explicit upgrade mechanisms.
For some multisignature or contract constructions, a separate key-aggregation or threshold-signing protocol can reduce the number of public keys and signatures visible on chain. For script policies with many alternatives, revealing one Merkle path can be smaller than revealing a full script containing every branch.
These are construction-dependent benefits. A large or deep script path can be expensive. A simple P2WPKH spend may be comparable or smaller in some dimensions. A service can use P2TR while retaining centralized custody. Taproot does not guarantee better privacy, lower fees, stronger backups, or safer wallet design.
What Taproot did not solve
Taproot did not remove blockchain transparency. It did not hide amounts, prevent address reuse, stop input clustering, or conceal every script spend. It did not add a general covenant mechanism, arbitrary computation, automatic privacy, or unlimited scaling.
It did not standardize every threshold-signing system. BIP 327 MuSig2 is separate. Other threshold protocols have separate assumptions, review histories, and implementation maturity.
It did not make all existing wallets compatible. Receiving requires correct Bech32m address support and output construction. Spending requires key management, signing, tree storage, PSBT or proprietary coordination, fee estimation, hardware support, and recovery design.
It also did not make experimental protocols built on Taproot part of Bitcoin consensus. A protocol can use Taproot outputs while adding separate servers, federations, bridges, or off-chain trust assumptions.
Activation and continuing support
BIPs 340, 341, and 342 were deployed together through the version-bits process specified by BIP 341. Bitcoin Core’s release-specific doc/bips.md records validation implementation in 0.21.0, mainnet activation support in 0.21.1, and the rules as always active beginning with version 24.0.
Activation means upgraded validation rules apply on the network. It does not measure the percentage of outputs using P2TR or the quality of wallet, exchange, signer, or service support.
Bitcoin Core 31.1 validates Taproot and includes P2TR descriptors and PSBT support. Its doc/bips.md records MuSig2 key aggregation through musig() descriptors in version 30.0 and signing support in version 31.0. Those are Bitcoin Core implementation milestones, not proof that other wallets or hardware devices interoperate.
Evaluating a Taproot claim
Ask which layer is being discussed:
- Consensus: Are BIP 340/341/342 validation rules active?
- Output construction: Can the wallet create the intended internal key and tree?
- Address encoding: Does it use Bech32m correctly for witness version 1?
- Signing: Does it support the required key-path, script-path, sighash, or threshold protocol?
- Coordination: Can all devices exchange the required scripts, control blocks, nonces, and PSBT fields?
- Recovery: Can the wallet reconstruct hidden branches and backups?
- Policy and relay: Will the transaction be accepted and propagated under current policy?
- Application adoption: Do counterparties actually recognize and use the output type?
Taproot is deployed consensus behavior. Everything built with it still needs separate evidence.