Taproot explained: BIP 340, 341 and 342

Taproot is the soft fork that activated at block 709,632 on 14 November 2021. It added a new output type, Pay-to-Taproot (P2TR, addresses starting with bc1p), that can be spent either with one Schnorr signature or by revealing a single script from a hidden tree. Three BIPs define it: BIP 340 (Schnorr signatures), BIP 341 (Taproot outputs) and BIP 342 (Tapscript). The stated goal was better privacy, efficiency and flexibility "without adding new security assumptions".

Updated 2026-10-20 · 7 min read

What is Taproot?

Taproot is SegWit version 1. SegWit left witness versions 1 to 16 undefined so later soft forks could use them, and Taproot gave version 1 its rules. A Taproot output commits to one public key, and that key can optionally hide a tree of alternative spending scripts. If everyone involved agrees, the coins move with a single signature and nobody learns that other conditions existed. If not, the spender reveals only the one script they use.

The three Taproot BIPs share authors. BIP 340 is by Pieter Wuille, Jonas Nick and Tim Ruffing. BIP 341 and BIP 342 are by Pieter Wuille, Jonas Nick and Anthony Towns. All three were created in January 2020 and activated together. BIP 341 credits Greg Maxwell, who first described the Taproot construction on the bitcoin-dev mailing list in January 2018.

Schnorr signatures (BIP 340)

Bitcoin originally used ECDSA. BIP 340 adds Schnorr signatures on the same secp256k1 curve with the same SHA-256 hash, so key generation and security assumptions about the curve stay the same. What changes:

• Smaller, fixed sizes. Signatures are always 64 bytes, instead of DER-encoded ECDSA signatures of up to 72 bytes. Public keys are 32 bytes ("x-only": only the X coordinate is stored) instead of 33.
• Provable security and no malleability. BIP 340 notes Schnorr signatures are provably secure under standard assumptions and non-malleable, while ECDSA signatures are "inherently malleable".
• Batch verification. A node can check many signatures together faster than one by one.
• Linearity. Signatures and keys can be added together, which is the basis for multisignatures, threshold signatures and adaptor signatures.

Linearity is what makes key aggregation possible, though BIP 340 itself only defines single-signer signatures. BIP 327 (Jonas Nick, Tim Ruffing, Elliott Jin) standardizes MuSig2: several people combine their public keys into one aggregate key and produce one ordinary-looking signature together. On chain, an n-of-n MuSig2 output looks exactly like a single-signer output. See BIP 340 vs BIP 327.

How Taproot outputs work (BIP 341)

A P2TR output script is OP_1 followed by a 32-byte key, 34 bytes in all. That key, the output key Q, is built from two parts:

• The internal key P: an ordinary public key, often a MuSig2 aggregate of everyone involved.
• An optional script tree: a Merkle tree whose leaves are scripts, each tagged with a leaf version. This is Bitcoin's form of MAST.

The two are combined by "tweaking": Q = P + t·G, where t is a tagged hash of P and the tree's Merkle root. Anyone who knows P and the root can check that Q commits to them, but Q on its own reveals nothing about the tree.

Key path and script path

The control block is 33 + 32m bytes: one byte holding the leaf version and a parity bit, the 32-byte internal key, and m hashes of the Merkle path, with a maximum depth of 128. Unused leaves stay hidden.

Two construction details from BIP 341 matter for wallets. If an output needs no scripts, the key should still be tweaked to commit to an unspendable script path (Q = P + hash(P)·G), so that, for example, no co-signer of an aggregate key can slip in a hidden script; BIP 86 wallets do exactly this. If an output should have no usable key path, the internal key can be a "nothing up my sleeve" point that nobody knows the private key for.

BIP 341 also introduced a new signature hash that commits to the amounts and scripts of all inputs being spent, which helps hardware wallets confirm fees, and a default sighash type (0x00) that lets signatures stay at 64 bytes. It reserves a witness element called the annex (marked by a first byte of 0x50) for future soft forks; it is signed but otherwise ignored today.

Tapscript (BIP 342)

Tapscript is the script language used for leaves with version 0xc0. It is close to SegWit v0 script, with these changes:

• OP_CHECKSIG and OP_CHECKSIGVERIFY verify BIP 340 Schnorr signatures.
• OP_CHECKMULTISIG is disabled. The new OP_CHECKSIGADD (opcode 186, 0xba) builds the same policies in a batch-verifiable way: <A> OP_CHECKSIG <B> OP_CHECKSIGADD <C> OP_CHECKSIGADD 2 OP_NUMEQUAL is a 2-of-3.
• OP_SUCCESSx upgrade hooks. Opcodes 80, 98, 126 to 129, 131 to 134, 137, 138, 141, 142, 149 to 153 and 187 to 254 make a script succeed unconditionally. A soft fork can give any of them a meaning later, and unlike the old OP_NOP hooks they may change the stack. Several covenant proposals, such as OP_CAT in BIP 347, use them.
• Unknown key types. A non-empty public key that is not 32 bytes is treated as a future key type whose signature checks pass, another hook for new signature schemes such as BIP 118.
• Limits. The 10,000-byte script size limit and the 201 non-push opcode limit do not apply. Signature checks no longer count toward the block-wide sigop limit; instead each input gets a budget of 50 plus its witness size in bytes, and every signature check spends 50. The 520-byte stack element and 1,000-element stack limits remain.

Taproot addresses: bc1p and bech32m

Taproot addresses start with bc1p (the "p" encodes witness version 1) and are 62 characters long on mainnet. They use bech32m from BIP 350 by Pieter Wuille rather than the original bech32. Bech32 had an unexpected weakness: when an address ends in "p", inserting or deleting "q" characters just before it can go undetected. Version 0 addresses were safe because only two lengths are valid, but future versions would not be, so BIP 350 changed one constant in the checksum (to 0x2bc830a3) for version 1 and later. See BIP 173 vs BIP 350 and the address types guide.

Wallet support was standardized in a handful of BIPs, all by Ava Chow (with Pieter Wuille on descriptors):

More background is in the PSBT, output descriptors and derivation paths guides; BIP 84 vs BIP 86 compares the SegWit and Taproot wallet layouts.

Privacy and fees: what Taproot does and doesn't change

Privacy. Key path spends all look alike, whether the key belongs to one person, a MuSig2 group or a contract whose parties agreed to close cooperatively. BIP 341 points out the limits: a script path spend reveals that a script path existed and that the key path wasn't used, and the depth of the revealed leaf leaks some information about the tree. Amounts, addresses and timing are as visible as ever, and a bc1p address is recognizable as Taproot.

Fees. For single-key wallets the difference is small. A P2TR output is 43 bytes against 31 for P2WPKH, but a key path input is about 57.5 vB against about 68 vB, because the witness is just one 64-byte signature with no public key. The bigger savings are for multisig and contracts: a MuSig2 spend costs the same as a single signature, and a script path spend pays only for the leaf it uses. The transaction size calculator shows the numbers.

Public keys. A P2TR output contains a public key rather than a hash of one. BIP 341 argues that hashing public keys gives protection against attacks on elliptic curves that is "very weak at best"; the quantum resistance guide covers the debate.

How Taproot activated

Taproot was deployed with version bits on bit 2, using a short signaling window that became known as Speedy Trial. BIP 341 records the mainnet parameters: signaling from 24 April 2021 to 11 August 2021 (median time past), a 90% threshold (1,815 of 2,016 blocks) instead of BIP 9's 95%, and a minimum activation height of 709,632. The threshold was reached and Taproot locked in during June 2021, then activated at block 709,632 on 14 November 2021. On signet the rules have always been active.

BIP 343, by Shinobius and Michael Folkson, described an alternative: a BIP 8 deployment with lock-in on timeout, designed to be compatible with Speedy Trial in case miner signaling fell short. Because Speedy Trial succeeded, that path was never needed. The soft forks guide compares these mechanisms.