When did Taproot activate on Bitcoin?

Taproot activated at block height 709632, which was mined on 14 November 2021 at 05:15 UTC. Signalling opened on 24 April 2021 with a timeout of 11 August 2021, using version bits on bit 2 with a threshold of 1815 blocks out of 2016, which is 90 percent rather than the usual 95. Lock-in was reached in June 2021, and activation was then deliberately held back to the fixed minimum activation height so node operators had months to upgrade.

What is the difference between key-path and script-path spending?

A Taproot output holds one public key, which is an internal key tweaked by the root of a Merkle tree of alternative spending conditions. A key-path spend happens when everyone cooperates: a single Schnorr signature moves the coins and the script tree is never published. A script-path spend is the fallback: the spender reveals one leaf script, its Merkle proof and the internal key. Only the branch actually used ever becomes public, and the other branches stay secret permanently.

What are Schnorr signatures and why do they matter?

Schnorr signatures are specified in BIP-340 and replace ECDSA for Taproot spends. They are 64 bytes rather than the 71 or 72 bytes a DER-encoded ECDSA signature typically takes, they have a security proof under cleaner assumptions, and they are linear. Linearity is the useful property: several signers can combine their keys and signatures into one aggregate that verifies as if a single party produced it, which is what lets a multisig arrangement spend at the same cost and appearance as a single-key wallet.

Is Taproot actually being used?

Less than most summaries imply, and the figure swings hard. Counting every transaction in three full blocks between 20 and 29 July 2026, Taproot accounted for 7.90, 3.01 and 1.76 percent of spent inputs, and 7.67, 0.97 and 1.02 percent of created outputs. Native SegWit version 0 held between 63 and 93 percent of inputs across the same blocks. Published trackers quote higher numbers over longer windows and different denominators, so any single headline percentage should be treated with suspicion.

Did Taproot make Bitcoin transactions cheaper?

For inputs, yes. A Taproot key-path input costs 57.5 virtual bytes against 68 for native SegWit version 0 and 148 for legacy. But Taproot outputs are larger, at 43 virtual bytes against 31, because the output commits to a full 32-byte key rather than a 20-byte hash. For an ordinary two-input, two-output payment those effects nearly cancel and slightly reverse. The real savings arrive with multisig and with transactions that spend many inputs.

Was Taproot the last change to Bitcoin's consensus rules?

As of July 2026, yes. Taproot activated in November 2021 and no consensus change has activated since. Proposals exist, including BIP-119 CHECKTEMPLATEVERIFY, whose status is still Draft, and BIP-347 OP_CAT in tapscript, whose status reads Complete. Complete describes the specification document, not the deployment, which is a distinction worth checking whenever a roadmap presents an idea as though it had shipped.

PillarTechnical

Taproot Explained: Bitcoin's Biggest Upgrade

Published July 29, 2026~11 min read

Taproot activated at block 709632 on 14 November 2021. It did three things: it replaced ECDSA with Schnorr signatures for the new output type, it let a single output carry a whole tree of alternative spending conditions, and it arranged matters so that when everyone cooperates, only one signature is ever published and nobody learns what the alternatives were.

That third item is the one worth understanding. Taproot's headline benefit is not speed and it is barely fees. It is that a 5-of-7 corporate treasury and one person moving pocket money can produce spends that are byte-for-byte indistinguishable.

Diagram of a Taproot output whose public key Q equals internal key P plus a hash of P and the Merkle root times the generator point. On the left the key path uses one 64-byte Schnorr signature and never publishes the tree. On the right the script path reveals a single highlighted leaf, its Merkle proof and the internal key, leaving three other leaves unknown. — Both routes lead out of the same bc1p address. An observer cannot tell in advance which routes exist, and after a key-path spend they never find out.Original diagram by BTCLinks. Output construction per BIP-341, verified 2026-07-29.

What actually changed?

Three specifications, deployed together. BIP-340 defines Schnorr signatures for secp256k1. BIP-341 defines the Taproot output type and its spending rules. BIP-342, usually called tapscript, defines what scripting looks like inside the new type. All three read Status: Deployed in the BIPs repository, alongside the two supporting specs that gave Taproot its address format and its derivation path.

Schnorr signatures are 64 bytes, against the 71 or 72 a DER-encoded ECDSA signature usually needs. Seven bytes is not why anyone cared. They cared because Schnorr signatures are linear, so keys and signatures can be added together. Several parties can combine into one key that spends with one signature, and the chain sees a single-key spend because that is genuinely what it is.

The Merkle tree of scripts is the second half. Instead of publishing every possible spending condition, a Taproot output commits to the root of a tree of them. The maths is on the diagram above: the output key Q is an internal key P tweaked by a hash of P and the Merkle root. If everyone signs, that tweak is never mentioned again. If they cannot, exactly one leaf gets revealed with a proof that it belonged to the tree.

It is worth being concrete about why linearity matters, because "signature aggregation" gets said a lot and explained rarely. With ECDSA, a 2-of-3 arrangement had to publish two separate signatures and enough script to prove which two were required. The witness grew with the complexity of the policy, and the policy itself became public the moment you spent. With Schnorr, the three parties can produce one combined key in advance and one combined signature at spending time. The chain sees a single key and a single signature, because at the level the chain cares about that is precisely what it is.

ECDSA and Schnorr signatures compared
	ECDSA	Schnorr (BIP-340)
Signature size	71 to 72 bytes, DER-encoded	64 bytes, fixed
Can keys be combined?	No	Yes, they add
A 2-of-3 spend publishes	Two signatures plus the policy	One signature, policy hidden
Batch verification	No	Yes, faster for full nodes
Security proof	Relies on stronger assumptions	Cleaner, under standard assumptions

The second row is the one that changes what is buildable. Everything Taproot does for multisig follows from keys being addable, and nothing in the fee column would have been worth an upgrade on its own.Table by BTCLinks, from the BIP-340 specification, verified 2026-07-29.

The catch is that combining signatures safely is harder than adding numbers. Naive schemes leak private keys to a malicious co-signer, which is why the protocols that do this properly need several communication rounds and careful nonce handling. That work happens in wallet software rather than in consensus, which is part of why the benefit took years to reach ordinary users even though the capability activated in 2021.

Tapscript quietly removed two limits that had been there since the beginning. The 10,000-byte cap on script size no longer applies, and neither does the 201 non-push opcode limit. Both were dropped for defensible reasons that BIP-342 spells out. Both also turned out to matter for something nobody was discussing in 2019, which we cover in the piece on Ordinals.

The three Taproot BIPs and what each one contributes
Spec	Title	BIP status	What it gave us
BIP-340	Schnorr Signatures for secp256k1	Deployed	64-byte signatures, linear so keys and signatures can be aggregated
BIP-341	Taproot: SegWit v1 spending rules	Deployed	The bc1p output type, key-path and script-path spending, the tweaked key
BIP-342	Validation of Taproot Scripts	Deployed	Tapscript. Dropped the 10,000-byte script cap and the 201-opcode limit
BIP-350	Bech32m for v1+ witness addresses	Deployed	The address encoding, with a fixed checksum constant
BIP-86	Key derivation for single-key P2TR	Deployed	The m/86'/0'/0' derivation path wallets use for Taproot accounts

Every row here reads Deployed, which is the status reserved for things the network actually runs. It is worth remembering the next time a roadmap describes something as done: a BIP marked Draft, or even Complete, has not necessarily been activated by anybody.Table by BTCLinks. Status lines read directly from the headers in the bitcoin/bips repository, verified 2026-07-29.

How did it activate without a war?

Bitcoin's previous consensus change had been ugly enough that the mechanism was redesigned before anyone attempted another one. The result was nicknamed Speedy Trial, and its parameters are spelled out in BIP-341's deployment section.

Signalling opened at midnight on 24 April 2021 and would have timed out at midnight on 11 August 2021. Miners signalled on bit 2, and the threshold was lowered from the customary 95 percent to 1815 blocks out of 2016, which is 90 percent. Lock-in came in June, well inside the window.

Then nothing happened for five months, on purpose.

Timeline showing Taproot signalling opening on 24 April 2021, lock-in in June 2021 at a threshold of 1815 of 2016 blocks, an unreached timeout date of 11 August 2021, and activation at block 709632 on 14 November 2021 at 05:15 UTC, with roughly five months marked between lock-in and activation. — The gap between lock-in and activation was the whole design. Miners chose the timing of the vote. They never got to choose the timing of the rules.Original diagram by BTCLinks. Parameters from BIP-341; block 709632 timestamp read from the chain, verified 2026-07-29.

That separation is the part worth taking away. A fixed min_activation_height of 709632 meant the new rules could not come into force early even with unanimous mining support, so every node operator had months of notice. Block 709632 was mined at 05:15 UTC on 14 November 2021, and Bitcoin has not changed its consensus rules since.

Is anyone actually using it?

Here the honest answer diverges from the usual one, so we counted rather than quoted.

We tallied every transaction in three full blocks spread across nine days in July 2026, classifying every input by the type of output it spent and every output by the type it created. Not a sample of each block. All of it.

Four and a half times' variation in nine days, from the same measurement on the same chain. This is why we distrust any single adoption headline, including one we could have written from this data.Original chart by BTCLinks. Every transaction in blocks 958807, 959407 and 960127 counted via the Blockstream Esplora API, 2026-07-29.

Two things stand out. The first is that Taproot's share of real spending is low: between 1.76 and 7.90 percent of inputs across those three blocks, while native SegWit version 0 held between 63 and 93 percent. Nearly five years after activation, most of Bitcoin still moves through bc1q.

The second is the volatility. A number that quadruples inside nine days is not measuring steady user adoption; it is measuring whatever burst of activity happened to fill those blocks. Published trackers report considerably higher Taproot figures over longer windows, and they are not necessarily wrong: they may be counting transactions rather than inputs, or weighting by volume, or averaging across months that include heavy inscription activity. Different denominators, different answers. That is the actual lesson, and it applies to every adoption chart you will ever be shown.

Script type breakdown across 16,847 transactions in three fully counted blocks
Script type	Share of inputs	Share of outputs
P2WPKH native SegWit v0	73.32%	46.77%
OP_RETURN data carrier	not spendable	37.61%
P2WSH SegWit v0 script	6.99%	4.42%
P2TR Taproot	4.41%	2.82%
P2PKH legacy	4.41%	2.08%
P2SH	3.77%	1.92%
Other or unclassified	7.10%	4.39%

Every input and output in blocks 958807, 959407 and 960127, which is 16,847 transactions, 22,334 inputs and 36,229 outputs. Two things to sit with: Taproot is level with legacy P2PKH on the input side, and more than a third of all outputs created were data carriers rather than payments.Table by BTCLinks, tallied via the Blockstream Esplora API, 2026-07-29.

Why so slow? Three reasons, and none of them is that Taproot is bad.

The first is that the fee saving for a plain payment is close to nothing, which we work through below. Nobody rewrites withdrawal infrastructure for a rounding error, and exchanges in particular have every incentive to leave working code alone.

The second is that the benefits land on the parties least likely to move quickly. Taproot pays off for multisig, for scripted conditions, for treasury arrangements. Those are exactly the setups where changing anything means a review, a new backup procedure, and a fresh set of recovery instructions for people who did not enjoy learning the last set.

The third is that address support has to be universal before it is useful. A receiving address is only worth switching to if everyone who might pay you can encode it. That was a real obstacle for years and it is mostly, though not entirely, behind us now.

The pattern is familiar. SegWit took years to pass half the network too, and it had a much stronger fee argument behind it. Bitcoin upgrades on the timescale of the slowest important participant, which is frustrating to watch and is arguably the system working correctly.

Did Taproot make transactions cheaper?

For inputs, clearly. A Taproot key-path input is 57.5 virtual bytes, against 68 for a native SegWit v0 input and 148 for legacy. Spending is where the discount lives.

For outputs, no. A Taproot output is 43 vbytes against 31 for P2WPKH, because it commits to a full 32-byte key rather than a 20-byte hash. On an ordinary two-input, two-output payment those two effects nearly cancel and then tip slightly the wrong way. We worked through the exact figures in the guide to address types, and the short version is that for a plain single-key payment the difference is worth a few dozen satoshis in the wrong direction.

Virtual byte costs by address type for single-signature spends
Type	Input vB	Output vB	2-in 2-out total
Legacy P2PKH	148	34	374
Native SegWit P2WPKH	68	31	208.5
Taproot P2TR, key path	57.5	43	211.5

The awkward row is the last one. Taproot has the cheapest input on the network and still loses a typical two-in, two-out payment by three virtual bytes, because its output is twelve bytes larger. At 20 sat/vB that is sixty satoshis, which is not a reason to do anything either way.Table by BTCLinks. Figures published by Bitcoin Optech, verified 2026-07-29.

So the fee case for an ordinary wallet is roughly a wash, and "roughly a wash" does not make exchanges rewrite withdrawal code. Where Taproot wins outright is narrower and more interesting:

Multisig. A cooperative spend of an aggregated multisig costs the same 57.5 vbytes as any single-key spend, instead of the much heavier witness a P2WSH multisig input carries. If you run a multisig wallet, this is the upgrade.
Input-heavy transactions. Consolidating many small outputs is all input cost, so the discount compounds and the larger output stops mattering.
Complex conditions. Inheritance timelocks, escrow, spending policies with several fallbacks. Under the old rules every branch had to be published; under Taproot the unused ones stay private forever. That matters directly for inheritance planning, where the whole arrangement used to be visible the moment you spent.

Where Taproot is worth switching to and where it makes no difference
What you are doing	Worth switching?	Why
Multisig of any kind	Yes, clearly	Cooperative spend costs 57.5 vB and looks like a single-key payment
Sweeping many small inputs	Yes	The input discount compounds; the bigger output stops mattering
Timelocks, escrow, inheritance	Yes	Unused branches are never published, so the policy stays private
Ordinary single-key payment	Barely	Smaller input, larger output. On a 2-in 2-out spend they cancel out
Receiving from an old exchange	No	Some software still cannot encode bc1p. Use bc1q and move on
Anything, versus a legacy 1 address	Yes	148 vB per input, forever. That is the gap that actually costs money

The honest summary of five years of Taproot: transformative for multisig and scripted conditions, close to irrelevant for one person paying for coffee. That gap explains the adoption curve better than any other factor.Table by BTCLinks, using the Bitcoin Optech vbyte figures cited above, verified 2026-07-29.

What does it do for privacy?

More than the fee story suggests, and it is structural rather than optional.

Before Taproot, a script's complexity was written on the chain whenever you spent. A 2-of-3 looked like a 2-of-3. A timelock announced itself. Anyone watching could infer how you stored your coins and often why. With a key-path Taproot spend, all of that vanishes into one 64-byte signature that looks like every other one.

The catch is that this only holds when everyone cooperates. Fall back to the script path and you publish the branch you used, and a script-path spend on a chain where most Taproot spends are key-path is itself a signal. The privacy is real but it is contingent, and the contingency is that your arrangement works as intended.

What a Taproot spend conceals and what it still reveals
Signal	Key-path spend	Script-path spend
How many keys were required	Hidden	Revealed for the branch used
That a timelock or fallback exists	Hidden	Revealed if you used it
The branches you did not use	Hidden	Still hidden
The amounts	Visible	Visible
Which inputs paid which outputs	Visible	Visible
That inputs likely share an owner	Visible	Visible

The third row is the one that has no equivalent under the old rules. Everything in the bottom half is untouched by Taproot and needs entirely different tools.Table by BTCLinks, derived from the BIP-341 spending rules, verified 2026-07-29.

Worth being precise about what Taproot does not do: it does not hide amounts, it does not break the link between inputs and outputs, and it does nothing about the assumption that all inputs to a transaction share an owner. Those need different tools, which we cover in Bitcoin privacy and CoinJoin.

Should you be using bc1p?

If you run multisig, yes, and it is the single best argument for switching. If you hold a lot of small outputs you will eventually sweep, yes. If you want the privacy properties on a complex spending policy, yes.

If you are one person with one key making ordinary payments, it genuinely does not matter much, and anyone insisting otherwise is overselling a few dozen satoshis. Both bc1q and bc1p are modern, both are cheap, and the meaningful gap is between either of them and a legacy 1 address, not between the two of them.

There is also a category of thing Taproot was expected to enable that has not really arrived, and it is worth naming rather than glossing over. The tree of scripts makes elaborate spending policies cheap and private, which in 2021 people expected to produce a wave of consumer products: shared custody with graceful fallbacks, inheritance that quietly activates, escrow that costs nothing when everyone behaves. Five years on, those exist mostly as capable software for people who already understand the problem, not as products your relatives could use. The constraint turned out not to be the protocol.

Two practical notes. Restoring a Taproot wallet needs the BIP-86 derivation path, m/86'/0'/0', and a wallet that only scans BIP-84 will show you an empty balance while the coins sit safely on a branch it never looked at. And a few older exchanges still cannot send to bc1p. That is a limitation of their software rather than of the network, and in 2026 it says something about how much engineering attention the company gets.

The last observation is about Bitcoin rather than Taproot. The most recent change to Bitcoin's consensus rules is now approaching five years old. Proposals are plentiful, and BIP-119 remains Draft while BIP-347 reads Complete, which describes a finished document and not a deployment. Whether that stability reads as calcification or as the system working exactly as intended is the argument underneath most Bitcoin development disputes, and it is worth noticing that the same fact is the strongest evidence for both positions.

Sources

BIP-341: Taproot, SegWit version 1 spending rules. Source of the output construction, the deployment parameters (start 24 April 2021, timeout 11 August 2021, threshold 1815 of 2016, min_activation_height 709632) and the line confirming the deployment did activate at that height. Verified 2026-07-29.
BIP-340: Schnorr Signatures for secp256k1. Status read as Deployed from the specification header. Verified 2026-07-29.
BIP-342: Validation of Taproot Scripts. Source of the resource-limit changes, quoted directly: the 10,000-byte maximum script size does not apply, the 201 non-push opcode limit does not apply, and the 520-byte stack element limit remains. Verified 2026-07-29.
Block 709632 on Blockstream Esplora. Confirms the activation block timestamp of 14 November 2021, 05:15:27 UTC. Verified 2026-07-29.
Blockstream Esplora API. Every transaction in blocks 958807, 959407 and 960127 was retrieved and classified by script type to produce the adoption chart. Counts: 3,898, 7,211 and 5,738 non-coinbase transactions respectively. Collected 2026-07-29.
Bitcoin Optech: Preparing for Taproot. Source of the 57.5, 68 and 148 vbyte input figures and the 43 and 31 vbyte output figures. Verified 2026-07-29.
BIP-119: CHECKTEMPLATEVERIFY. Status read as Draft. Verified 2026-07-29.
BIP-347: OP_CAT in Tapscript. Status read as Complete, layer Consensus (soft fork), confirming the specification is finished rather than activated. Verified 2026-07-29.

Some links are affiliate links. As an Amazon Associate we earn from qualifying purchases. Not financial advice.