Tapscript

Tapscript is the version of Bitcoin Script used when a Taproot output is spent via its script path. Specified in BIP342 alongside BIP341 and activated with the Taproot upgrade in November 2021, it keeps most of legacy Script familiar while modernising signature handling and — crucially — making future soft-fork upgrades far easier. If Taproot is the new address and commitment structure, Tapscript is the new rulebook that governs what a revealed script branch may do.

What changed from legacy Script

Tapscript validates Schnorr signatures rather than ECDSA, inheriting Schnorr's efficiency and batch-verification friendliness. The batch-unfriendly OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY are disabled and replaced by OP_CHECKSIGADD, a small opcode that increments a counter when a signature check succeeds, letting scripts tally signatures efficiently for k-of-n multisig policies. Resource limits were rethought as well: the old 201-opcode-per-script cap is dropped in favour of a signature-operations budget that scales with the size of the witness, and the rigid 520-byte element and 10,000-byte script constraints are relaxed. The practical result is that complex spending policies — timelocked recovery paths, large multisig trees, hash-locked branches — are cheaper and cleaner to express than they ever were under P2SH.

Each leaf in the script tree also carries a leaf version (Tapscript is version 0xc0), a second upgrade dimension: future soft forks can introduce entirely new script versions without touching existing ones. Spending cost splits cleanly, too — a key-path spend is just a single Schnorr signature, the cheapest spend Bitcoin offers, while a script-path spend pays for the revealed script plus its Merkle control block. Well-designed wallets therefore arrange the common case on the key path and reserve the tree for exceptions.

Adoption has followed exactly that shape. Modern descriptor wallets express Taproot outputs natively, and key-aggregation schemes like MuSig2 let a multisig quorum collapse into one aggregate key on the key path — the full policy tree waiting silently in the Tapscript branches as a fallback that, in the happy case, nobody ever sees or pays for.

Built for upgrades

The most forward-looking change is the smallest. Tapscript redefines a set of unused opcodes as OP_SUCCESS opcodes: encountering one makes the entire script succeed unconditionally. That sounds dangerous, but it is a deliberate upgrade mechanism — a future soft fork can assign one of these opcodes real semantics, and because old nodes already treat it as "anything goes," tightening its meaning only restricts what was previously valid. That is exactly the shape a soft fork must have. Each OP_SUCCESS is effectively a reserved slot for new functionality, a far cleaner path than the disabled-opcode graveyard of earlier Script. Proposals like SIGHASH_ANYPREVOUT and various covenant opcodes are designed with this deployment route in mind.

Privacy and what it enables

Because a Taproot output reveals a script branch only when that branch is actually used, Tapscript spends keep every unused condition private. A wallet with a three-of-five recovery quorum, a timelocked inheritance path, and a simple single-key happy path looks, in the common case, identical on-chain to the plainest single-signature spend. Only the executed branch — and a Merkle proof that it belonged to the tree — is ever published, a marked improvement over legacy P2SH, which exposed the entire script at spend time. Combined with the new default sighash behaviour and the witness discount measured in weight units, this makes rich policies cheap and discreet.

For the sovereign holder, Tapscript is not an abstraction to admire from a distance: it is the machinery underneath modern descriptor wallets, efficient multisig vault designs, and much of the covenant research aimed at safer self-custody. Understanding that the script path exists, costs more than the key path, and stays hidden until used is the key to reading any modern Bitcoin wallet's trade-offs.