Taproot explained: Schnorr signatures, hidden scripts and Bitcoin’s 2021 upgrade

Taproot is three proposals that only make sense together

Taproot is the everyday name for a bundle of three Bitcoin Improvement Proposals that activated at the same time. BIP340 defines Schnorr signatures for Bitcoin’s curve. BIP341 defines Taproot itself: a new kind of output and the rules for spending it. BIP342 defines Tapscript, the updated scripting rules that run inside those outputs. Pieter Wuille, Jonas Nick and Anthony Towns wrote 341 and 342; Wuille, Nick and Tim Ruffing wrote 340.

BIP341 states the goal as improving “privacy, efficiency, and flexibility of Bitcoin’s scripting capabilities without adding new security assumptions.” The authors note that Schnorr signatures, Merkle branches (an idea earlier proposals called MAST) and Taproot had each been proposed separately, and that combining them “in a single proposal would be an extensive change,” so they were split into three documents that were designed and deployed as one.

Everything below is built on the SegWit upgrade of 2017, which gave each output a version number. Taproot outputs are SegWit version 1; the older native SegWit outputs are version 0. That versioning is what allowed a change this large to be introduced as a soft fork, meaning older nodes continue to accept the new blocks without understanding the new rules.

Schnorr signatures: a cleaner signature that can be added together

Bitcoin launched with a signature scheme called ECDSA. It works, but it has awkward properties. Its security proof rests on stronger assumptions than cryptographers would like, its signatures come in a variable-length encoding, and a signature can be altered into a different valid form by anyone who sees it, which is the malleability problem that SegWit had to work around.

BIP340 specifies Schnorr signatures for the same curve Bitcoin already uses, so no new cryptographic assumption is introduced. The proposal says Schnorr signatures are “provably secure” under standard assumptions, that they are not malleable, and that they are a fixed 64 bytes with 32-byte public keys, one byte shorter than before. Nodes can also verify many Schnorr signatures in a single batch, which is faster than checking them one at a time.

The property that matters most is linearity. Because of how the math works, BIP340 explains, Schnorr “enables multiple collaborating parties to produce a signature that is valid for the sum of their public keys.” Three people sharing control of a coin can publish one combined key and one combined signature, and on the chain it looks exactly like one person spending one coin. Under ECDSA a multi-signature spend had to reveal every key and every signature.

The key path and the script path: two doors into the same coin

A Taproot output contains a single public key, which BIP341 calls the output key. That key is built from two ingredients: an internal key, which might be one person’s key or an aggregate of several, and the root of a Merkle tree whose leaves are scripts, each describing an alternative way to spend the coin. The proposal defines the output key as the internal key plus a hash of the internal key and the tree root, so the tree is committed inside the key without being visible.

The simplest way to spend is the key path: whoever controls the internal key signs with a Schnorr signature, and that is the whole witness. Nothing about the tree is revealed. BIP341 spells out the privacy consequence: “As long as the key-based spending path is used for spending, it is not revealed whether a script path was permitted.” A plain single-signature wallet, a two-of-three multisig and a complex contract with a dozen fallback conditions all look the same.

The other way is the script path. If the parties cannot or will not cooperate on a key-path spend, the spender reveals one leaf script, the Merkle branch that proves it belongs to the tree, and whatever the script requires. The other leaves stay hidden. This is the Merkle-branch idea, often called MAST, and it means a coin can carry many spending conditions while only ever revealing the one that gets used.

Tapscript changes how scripts check signatures

Scripts revealed on the script path run under BIP342’s rules, which the proposal calls Tapscript. The signature-checking operations now verify Schnorr signatures instead of ECDSA. The old multi-signature opcode, OP_CHECKMULTISIG, is disabled, because it was awkward to verify in batches. In its place there is OP_CHECKSIGADD, which counts valid signatures one at a time so that a rule such as “any two of these three keys” can be written efficiently and batch-verified.

Tapscript also reserves a set of unused opcodes as OP_SUCCESS. Any script containing one is treated as automatically valid today, which sounds odd until you see the purpose: a future soft fork can assign meaning to one of those opcodes without breaking anything, because today’s nodes were already accepting it. BIP342 frames the whole document as making “Schnorr signatures, batch validation, and signature hash” improvements available inside scripts, not just for key-path spends.

Addresses that start with bc1p

Taproot outputs are written as addresses using Bech32m, defined in BIP350 by Pieter Wuille. Bech32m is a small fix to the Bech32 format that SegWit introduced. The original had an unexpected weakness: BIP350 explains that “whenever the final character is a ‘p’, inserting or deleting any number of ‘q’ characters immediately preceding it does not invalidate the checksum.” Version 0 addresses were safe because of their fixed lengths, but future versions would not have been.

So version 0 addresses keep using Bech32, and version 1 and above use Bech32m, which changes one constant in the checksum. A mainnet Taproot address begins with bc1p. Sending to one from an older wallet that does not understand Bech32m will fail rather than silently misdirect coins, which was the intent. Our guide to Bitcoin address types shows the formats side by side.

Speedy Trial: how Taproot activated in November 2021

Bitcoin Core 0.21.1, released on 1 May 2021, carried the activation logic. The method, nicknamed Speedy Trial, was a variation of the BIP9 version-bits signaling used for SegWit, with two differences. The window was short: if 90% of the blocks in any 2,016-block period signaled on bit 2 between 24 April and 11 August 2021, Taproot would lock in; if not, the attempt would simply expire. And there was a minimum activation height of 709,632, so even after locking in, the rules would not switch on until that block, giving everyone months to upgrade.

The contrast with SegWit was deliberate. SegWit’s signaling dragged on for most of a year and became entangled in the block size war. Taproot had no comparable opposition, and the release notes encouraged “all users, businesses, and miners” to upgrade “unless they object to activation of taproot.” Miners reached the threshold within the window.

Block 709,632 was mined by F2Pool on 14 November 2021 at 05:15 UTC, with 2,043 transactions. Bitcoin Optech’s newsletter that week confirmed that the soft fork “activated at block height 709,632,” and noted a wrinkle: several large mining pools were not yet including Taproot spends in their blocks, most likely because their transaction-selection software had not caught up with their signaling. The newsletter’s advice was to run your own Taproot-enforcing node rather than rely on what pools do.

Compare what a key-path spend and a script-path spend disclose

For a key-path spend, the on-chain witness supplies a signature for the output key. For a script-path spend, it supplies the executed script and the information needed to prove that script belongs to the committed tree. Unused script branches do not have to be published in full.

This is a statement about the spending conditions exposed by those paths. It is not a promise that transaction amounts, timing, or outside information stop being useful for analysis. When a claim says “Taproot improves privacy,” ask which construction and which spending path the claim describes.