Today marks the activation anniversary of Taproot, one of Bitcoin’s most important upgrades since SegWit.
On November 14, 2021, at block 709,632, Taproot went live on Bitcoin via a soft fork. It bundled three Bitcoin Improvement Proposals (BIPs):
BIP340 – Schnorr signatures
BIP341 – Taproot (new output type + commitment structure)
BIP342 – Tapscript (new script version and rules)
Greg Maxwell first proposed the Taproot idea in 2018, and the BIPs were primarily authored and driven by Pieter Wuille, Jonas Nick, and Tim Ruffing, along with contributions from A.J. Towns and others.
This post is my attempt to frame Taproot as what it really is:
A low-level upgrade that quietly turned Bitcoin into a more private, efficient, and flexible platform for smart, rule-based Bitcoin ownership.
Why Taproot? The core motivation
You can summarise Taproot’s goals in three words:
Privacy, efficiency, flexibility.
1. Privacy
Before Taproot:
Different spending policies left different on-chain fingerprints.
Single-sig, multisig, Lightning channels, DLCs, recovery scripts. All looked different.
If you used a complex script (e.g., 2-of-3 multisig with a timelock backup), spending it meant revealing the entire script on-chain:
All participants
All backup conditions
All “what if things go wrong?” paths
That’s bad for privacy (the world sees your setup) and fungibility (some coins look more “complex” or “weird” than others).
Taproot changes that:
Most Taproot spends can look like a simple key + single signature, even if behind the scenes it’s a multisig wallet or a smart contract-like arrangement.
If you do need a script, Taproot only reveals the one script branch you actually use, not the whole decision tree.
So complex contracts can “hide in plain sight” as a normal transaction until they need to reveal a specific condition.
2. Efficiency
Before Taproot:
Multisig = multiple public keys + multiple signatures on-chain.
Complex scripts = more bytes = more fees.
Everything had to be verified individually.
Taproot introduces Schnorr signatures (BIP340):
Multiple parties can cooperate to produce a single aggregated public key and a single signature.
On-chain, a 3-of-3 multisig can look like:
1 key
1 signature
This reduces:
Transaction size
Fee cost
Verification cost per block
This makes advanced setups (multisig, shared custody, L2 protocols) more affordable and scalable.
3. Flexibility
Bitcoin Script was always powerful in theory, but clunky in practice:
All script branches had to be revealed when used.
Script size and validation rules were more rigid.
Adding new capabilities was politically and technically hard.
Taproot’s answer: Tapscript (BIP342).
It’s a new script version that:
Works nicely with Schnorr signatures.
Removes some old limits.
Is explicitly designed to be extensible for future opcodes and use cases.
This “future-proof” scripting layer is what makes Taproot feel like a foundation for smart contracts on Bitcoin, not in the Ethereum sense of infinite complexity, but in the Bitcoin way: constrained, auditable, but much more expressive than before.
How Taproot UTXOs actually work?
Let’s zoom in on the UTXO side and clean up a few concepts.
Before Taproot: scripts all the way down
Every UTXO is basically:
“Some sats + a locking script (scriptPubKey) that describes who can spend this and how.”
Pre-Taproot:
You either had a key-based output (e.g., P2PKH, P2WPKH)
→ “Prove you control this public key.”
Or a script-based output (P2SH, P2WSH)
→ “Here’s a hash of a script; when spending, reveal the full script and satisfy it.”
If you used a script with multiple branches (e.g., normal spend + recovery + timeout), the entire script had to be revealed when you used it, even if you only used one branch.
Taproot: key path + script path
Taproot introduces a new output type: P2TR (Pay-to-Taproot).
A Taproot output commits to:
An internal public key (base key).
Optionally, a Merkle tree of scripts (MAST – Merkelized Alternative Script Tree).
These get combined (or “tweaked”) into a single Taproot output key. On-chain, the UTXO just looks like:
“Pay to this 32-byte x-only public key.”
Now there are two ways to spend it:
1. Key path spend
All parties involved have combined their keys into a single aggregated key (using something like MuSig2 or a simpler aggregation scheme).
They produce one Schnorr signature for the Taproot output key.
On-chain: looks exactly like a simple single-sig spend.
This is the “happy path” and what delivers the best privacy and efficiency.
2. Script path spend
If something goes wrong or a special condition is needed (recovery, timeout, dispute resolution, etc.):
You reveal only the script branch (leaf) you’re executing, plus:
A control block proving that leaf is part of the committed Merkle tree.
The rest of the tree (other backup branches) stays hidden.
So you get:
Key path → fast, cheap, private.
Script path → flexible, with selective disclosure of only what’s needed.
You don’t use both in the same spend, each spend is either key path or script path.
Why Taproot matters for “smart contracts” on Bitcoin
Taproot didn’t turn Bitcoin into Ethereum. It did something more Bitcoin-native:
It kept the UTXO model and simple base layer.
It made complex spending policies:
Cheaper (signature aggregation, smaller scripts).
More private (key path spends, selective script reveal).
More powerful (Tapscript + MAST + future upgrades).
That’s why so many newer ideas, vaults, DLCs, Ark-style designs, BitVM-style constructions, advanced multisig, and better Lightning channel constructions, all lean on Taproot as their base.
Taproot is not a flashy “dApp platform” feature. It’s a structural upgrade that quietly made Bitcoin a better place to build non-custodial, contract-like behavior, while staying true to Bitcoin’s values.
Disclaimers
This article was written with editorial assistance from ChatGPT 5. All ideas, research, and conclusions are my own