Magazine · Mining & technology
Taproot and Schnorr: What the Last Big Upgrade Brought
Taproot and Schnorr explained: shorter signatures, MuSig2, hidden script trees, bc1p addresses, fees, privacy and the Ordinals side effect.
Taproot is Bitcoin's last big upgrade, active since 14 November 2021 (block 709’632). It brought Schnorr signatures, which are shorter than the old ones and can be combined into a single one. It also added script trees, where only the condition actually used becomes visible. The result: a wallet with several keys can look and cost like a simple payment on the blockchain.
How Bitcoin gets new rules at all, and how Taproot was activated in 2021 with "Speedy Trial", is explained in the article Bitcoin soft fork. This article is about the upgrade itself: what is in it technically, what it does for you and what became of it. All figures are as of November 2026.
Three building blocks, one upgrade
Taproot consists of three Bitcoin Improvement Proposals that only make sense together:
| BIP | Name | What it brings |
|---|---|---|
| BIP 340 | Schnorr signatures | new signature scheme, 64 bytes, combinable |
| BIP 341 | Taproot | new address type (SegWit version 1), key path and script path, script trees |
| BIP 342 | Tapscript | revised script language for the conditions in the tree |
The idea goes back to a post by Gregory Maxwell on the Bitcoin developer mailing list in January 2018. The BIPs were written mainly by Pieter Wuille, Jonas Nick, Tim Ruffing and Anthony Towns. Almost four years passed from idea to activation.
Schnorr signatures: shorter and combinable
Every Bitcoin payment needs a digital signature. It proves that the owner of the private key agrees, without revealing the key. Until 2021 Bitcoin used only ECDSA for this. Taproot adds Schnorr signatures on the same elliptic curve, secp256k1. Your seed phrase and your keys stay the same kind of number.
Why didn't Satoshi choose Schnorr in the first place? The scheme was patented until 2008, and there was no widely used standard for it. ECDSA was free and available in libraries.
Schnorr has three advantages over ECDSA:
- Shorter. A Schnorr signature is always exactly 64 bytes, an ECDSA signature usually 71 to 72 bytes. The public key also shrinks from 33 to 32 bytes.
- Cleanly provable. The security of Schnorr can be proven mathematically under well-understood assumptions. For ECDSA that is only possible in a limited way.
- Linear. This is the real reason for the upgrade. Signatures and keys can be added together. Two people can form a joint key and produce a single signature for it together.
How a Schnorr signature works
Notation: G is the fixed starting point of the curve, x your private key, P = x·G your public key, m the message (the transaction), H a hash function (SHA-256 with a "tag").
Signing:
- Choose a secret random number k (nonce) and compute R = k·G.
- Compute e = H(R ‖ P ‖ m).
- Compute s = k + e·x.
- The signature is (R, s): 32 bytes for the x-coordinate of R, 32 bytes for s, 64 bytes in total.
Verifying: Anyone can check whether s·G = R + e·P. It holds because s·G = k·G + e·x·G = R + e·P.
Linearity: If Anna (x₁) and Ben (x₂) have a joint key P = P₁ + P₂ and both choose a nonce with R = R₁ + R₂, then s = s₁ + s₂ is a valid signature for P. Neither of them knows the whole private key x₁ + x₂.
With ECDSA this does not work, because there the nonce divides: s = k⁻¹·(H(m) + r·x). That formula cannot simply be added up.
MuSig2: many keys, one signature
Simple addition has a gap: one participant could choose their key so that it cancels out the others' keys, and then sign alone. The MuSig2 scheme (BIP 327, written up as a standard in 2023) prevents this. Each key gets its own factor, which depends on all the keys involved.
On top of that comes a two-round process: first everyone exchanges two nonces, then their partial signatures. The first round can be prepared before the transaction is even known.
Important: MuSig2 is an n-of-n scheme. Everyone involved must take part. So a 2-of-3 wallet is built with Taproot like this: the two keys that normally sign form the main key via MuSig2. The other combinations sit in the script tree as fallback paths. True threshold signatures such as "3 of 5 in one signature" (FROST) are in development, but as of November 2026 still the exception in widely used wallets.
How MuSig2 forms the joint key
For the keys P₁ … Pₙ, let L be the list of all keys.
- Factor per key: aᵢ = H(L ‖ Pᵢ)
- Joint key: P = a₁·P₁ + a₂·P₂ + … + aₙ·Pₙ
- Each participant contributes two nonces (Rᵢ,₁ and Rᵢ,₂). From them a joint R is formed that also depends on the message. This allows two rounds instead of three and stays secure even when several signing sessions run in parallel.
- Partial signature: sᵢ = kᵢ + e·aᵢ·xᵢ, total signature s = s₁ + … + sₙ.
The result is an ordinary 64-byte signature for an ordinary 32-byte key. Nobody can tell from the outside how many people were involved.
Script trees: conditions nobody sees
Bitcoin can do more than "one key, one signature". A wallet can have conditions, for example: "Anna and Ben together, or Anna and the notary, or Ben alone after one year." Before Taproot you had to reveal the whole rulebook when spending, including the parts you didn't use. That took space and revealed a lot about your setup.
Taproot arranges the conditions in a tree (MAST, "Merklized Alternative Script Tree"). Each condition is a leaf. The address only contains a fingerprint of the whole tree. When spending you show:
- the one leaf you use,
- the proof that it belongs to the tree (32 bytes per level),
- the signatures this leaf requires.
All other leaves stay hidden forever.
Key path and script path
Taproot's real trick combines both. Every Taproot address has a main key and optionally a script tree. The tree is "folded into" the main key (the tweak). That gives two ways to spend:
- Key path: a single Schnorr signature for the main key is enough. Nobody can see whether a tree is behind it.
- Script path: you use a leaf of the tree. Then it becomes visible that there was a tree, and which leaf you chose.
So the normal case runs through the key path, and the tree is the fallback. A simple wallet with one key has no tree at all. It always uses the key path.
How the tree sits inside the key (BIP 341)
- Leaf: hᵢ = H_TapLeaf(version ‖ length ‖ script)
- Branch: H_TapBranch(a ‖ b), with a and b sorted
- Root: the top branch, called the Merkle root r
- Tweak: t = H_TapTweak(P ‖ r)
- Output key: Q = P + t·G
Q sits in the address as 32 bytes (SegWit version 1, bc1p). On the key path you sign directly for Q with the private key x + t. On the script path you reveal P, the leaf and the sibling hashes (control block: 33 + 32 × depth bytes), and anyone checks that they produce Q. A tree may be up to 128 levels deep.
Tapscript: the revised script language
BIP 342 defines how the leaves are written. Three changes matter:
- CHECKSIGADD instead of CHECKMULTISIG. The old multisig opcode had to try each signature against several keys. The new one simply counts valid signatures, and each signature is checked only once.
- Limits redrawn. The old limit of 10’000 bytes per script and 201 opcodes is gone. Instead, the validation budget depends on the size of the data. This change became important later, see inscriptions.
- Room for future upgrades. Unused opcodes are reserved as "OP_SUCCESS". A later soft fork can give them a meaning without reinventing the script language.
Privacy: multisig looks like single-sig
Before Taproot, a 2-of-3 wallet was instantly recognisable on the blockchain. When spending, all three public keys and the two signatures were out in the open.
With Taproot and MuSig2 the normal case produces one signature for one key, exactly like a simple phone wallet. Someone reading the blockchain sees no difference. The same applies to Lightning channels when both sides close cooperatively and the software uses Taproot channels. How Lightning works is explained in the article Lightning Network.
There are still limits:
- The script path gives something away. If you use a fallback path, people can see there was a tree, and the leaf used.
- Few people use bc1p. As long as only a small share of payments use Taproot, a bc1p address stands out more than a bc1q address.
- Amounts and links stay visible. Taproot hides conditions, not who sends how much to whom.
What Taproot changes for fees
Bitcoin fees depend on the space a transaction takes in vbytes, not on the amount. Taproot shifts this space: a Taproot output is slightly larger at 43 vbytes than a SegWit output (31 vbytes), because it holds the whole key instead of a hash. A Taproot input is smaller at 57.5 vbytes (SegWit: 68 vbytes). The comparison for simple wallets is in the article Bitcoin addresses and the soft fork article. This section is about wallets with several keys, where the difference gets large.
Where the vbyte figures come from
An input has 41 bytes outside the witness (outpoint 36, length 1, sequence 4). They count four times: 164 weight units (WU). Witness data counts once. vbytes = WU ÷ 4.
- Taproot, key path: witness = 1 (count) + 1 + 64 (signature) = 66 WU. Total 230 WU = 57.5 vbytes. The same for 1, 2 or 5 participants.
- SegWit 2 of 3: witness = 1 + 1 (empty element) + 2 × 73 (signatures) + 1 + 105 (script with three keys) = 254 WU. Total 418 WU = 104.5 vbytes.
- Taproot, script path 2 of 2 in a tree with two leaves: witness = 1 + 2 × 65 (signatures) + 1 + 68 (script) + 1 + 65 (control block) = 266 WU. Total 430 WU = 107.5 vbytes.
- SegWit 3 of 5: witness = 1 + 1 + 3 × 73 + 1 + 173 = 395 WU. Total 559 WU = 139.75 vbytes.
Fee = vbytes × fee rate, e.g. 57.5 × 20 = 1’150 sats. ECDSA signatures vary by a byte, hence "about".
What these sats are worth in euros or francs, you can convert here:
Who uses Taproot: adoption as of November 2026
Taproot has been active for five years, but it is not yet the standard for saving. According to Glassnode, about 222’000 BTC sat on Taproot addresses on 10 November 2026, just over 1 % of all bitcoin. The vast majority still sits on bc1q, 3 and 1 addresses.
There are understandable reasons:
- For a simple wallet the advantage is small. If you rarely spend, bc1p saves you hardly anything.
- Multisig with MuSig2 came late. The MuSig2 standard only appeared in 2023. Hardware wallets and coordination software first have to implement it. For the usual private 2-of-3 wallet, MuSig2 is still the exception as of November 2026.
- Sending works almost everywhere, receiving doesn't. Almost all current wallets and large exchanges send to bc1p. Many wallets create their own bc1p addresses, but not all.
For large long-term holdings there is also an argument against bc1p: the public key sits directly in the address, not just as a hash. A future quantum computer would have a point of attack here. How serious that is today is assessed in the article Quantum computers and Bitcoin.
The unexpected use: inscriptions and Ordinals
Nobody planned Taproot's best-known application. In January 2023 Casey Rodarmor launched the Ordinals project. It has two parts:
- Ordinals are a way of counting: every satoshi gets a number according to the order in which it was mined. This is only a convention outside Bitcoin's rules.
- Inscriptions write data (images, text, later also tokens such as "BRC-20") into a Taproot script, in a section that is never executed (OP_FALSE OP_IF … OP_ENDIF). The data ends up in the witness part of the transaction.
Three properties made this attractive: since SegWit, witness data counts only a quarter; Tapscript lifted the old limit of 10’000 bytes per script; and a block may hold up to 4 million weight units. In early 2023 a single image filled almost an entire block this way.
Everyone felt the consequences: in several waves in 2023 and 2024, fees rose sharply at times, because inscriptions bid for the same block space as normal payments. For miners it was extra income, for savers with many small amounts it was expensive. The question of whether Bitcoin should limit such data led to heated debates in 2025 and 2026, up to the failed proposal BIP 110. The details are in the soft fork article.
What Taproot means for you
- Simple wallet: bc1q and bc1p are both good. For large, dormant holdings bc1q is the more cautious choice by today's standards, because of the quantum argument.
- Multisig: this is where the big benefit lies. Check whether your software supports Taproot multisig with MuSig2 and whether all your devices play along. Until then, the proven bc1q multisig remains a solid solution.
- No need to do anything: your old addresses keep working. Taproot is an option, not an obligation.
Frequently asked questions
When was Taproot activated?
On 14 November 2021 with block 709’632. Miners had already signalled the required 90 % support in June 2021. The months up to the fixed activation height gave wallets and node operators time to update.
What is the difference between Schnorr and ECDSA?
Both sign on the same curve with the same keys. Schnorr signatures are shorter (64 instead of usually 71 to 72 bytes), mathematically more cleanly provable, and they can be added together. That lets several people produce a single joint signature.
Is a bc1p address more secure than bc1q?
Not in principle. Both are secure by today's standards. bc1p saves a little when spending and protects privacy with multisig. bc1q only reveals your public key when you spend, which is more cautious with future quantum computers in mind.
Is MuSig2 the same as multisig?
No. Classic multisig checks several signatures one by one, for example 2 of 3. MuSig2 combines the keys and signatures of all participants into one, and everyone must take part (n of n). With Taproot you combine both: MuSig2 for the normal case, script leaves for the fallback paths.
Do Ordinals have anything to do with Taproot?
The numbering of satoshis doesn't; it is only a way of counting. Inscriptions, on the other hand, use Taproot scripts to place data in the witness. That was made possible by SegWit's witness discount and Tapscript's removal of the script size limit.
Sources
Not financial, legal or tax advice. Models are no guarantee.
The Bitcoin Power Law newsletter
An email when we publish a new article or calculator. Every issue has a one-click unsubscribe link.