Block 481,824, stamped 01:57:37 UTC on 24 August 2017, holds 1,866 transactions in 989,323 bytes and weighs 3,954,880 units: it fits the old 1 MB ceiling and the new 4 million-unit one at the same time, with only about 800 bytes of witness data. Block 709,632, stamped 05:15:27 UTC on 14 November 2021, is 1,410,904 bytes long, well past 1 MB, yet weighs 3,881,749 units, because some 587,000 of its bytes are witness. The first opened SegWit, the second Taproot. The gap between their sizes is the shortest way into SegWit vs Taproot: what each upgrade changed, and why the second needed the first.
Both are soft forks of Bitcoin’s transaction format, and both came in through the same door. Version 0 of the witness, SegWit, took signatures out of the transaction ID and introduced weight. Version 1, Taproot, brought Schnorr signatures, a tree of hidden spending scripts and a spend that looks the same whether one key or a committee stands behind it. In the 144 blocks mined up to 09:30 UTC on 9 November 2026, 89.9 percent of transactions carried witness data, by Coindaro’s count of raw blocks detailed below.
This lesson follows the previous one in the path, how Bitcoin transactions and scripts work, which takes a transaction apart byte by byte, runs a P2PKH script one opcode at a time and lists the output types with their address prefixes. Those mechanics are assumed here. What follows is what changed in 2017 and 2021, and what it cost.
SegWit vs Taproot: two upgrades through the same door
A soft fork tightens the rules so that blocks made by upgraded miners stay valid for nodes that never upgraded. Our guide to soft forks and hard forks explains the difference, how miners signal with a version bit, and the 2017 SegWit saga, from the stalled 95 percent vote and the BIP 148 deadline of 1 August to Taproot’s shorter Speedy Trial window in 2021. Only one detail of that machinery matters here: the trick that made both upgrades possible.
SegWit defined a new kind of output, the witness program: a small number from 0 to 16 (the version) followed by 2 to 40 bytes of data. To a node running pre-2017 software, such an output is a script that pushes two items and leaves a non-zero value on the stack, so anyone can spend it with an empty proof. To an upgraded node, the version number picks a set of rules, and the proof must sit in a new place, the witness. BIP 141 says it plainly: non-upgraded nodes “will consider all witness programs as anyone-can-spend scripts”. Old nodes never see a coin stolen, because miners enforcing the new rules never put such a theft in a block.
Version 0 was used by SegWit in 2017. Version 1 was left undefined, so it stayed anyone-can-spend, until Taproot gave it rules in 2021. BIP 341 repeats the argument almost word for word: “Non-upgraded nodes, however, will consider all SegWit version 1 witness programs as anyone-can-spend scripts.” Versions 2 to 16 are still free today, which is how any future change of the same kind would arrive.
From proposal to active rule, block by block
One piece of the 2017 route is missing from most short accounts. BIP 91, a miner-run rule with a threshold of 269 blocks out of 336 (80 percent), was written as a way to activate the existing deployment “with a majority hashpower less than 95%”: once active, from block 477,120, it rejected every block that did not signal SegWit. The heights below were checked on mempool.space; times are block timestamps, which can be off from real time by an hour or more.
| Date (block timestamp, UTC) | Block | Event |
|---|---|---|
| 21 Dec 2015 | BIP 141 (Segregated Witness) assigned its number | |
| 27 Oct 2016 | Bitcoin Core 0.13.1 released with the SegWit deployment code | |
| 15 Nov 2016 | BIP 9 signalling for “segwit” (bit 1) opens | |
| 21 Jul 2017 | 476,784 | BIP 91 locked in from the 336-block period starting here |
| 23 Jul 2017 | 477,120 | BIP 91 active: blocks that do not signal SegWit are rejected |
| 9 Aug 2017, 12:36 | 479,808 | First block of the period in which SegWit is locked in |
| 24 Aug 2017, 01:57 | 481,824 | SegWit active, exactly 2,016 blocks later |
| 24 Apr 2021 | Taproot signalling window opens (bit 2, 1,815 of 2,016 blocks) | |
| 13 Jun 2021, 20:06 | 687,455 | Last block of the period in which the 90 percent threshold was crossed |
| 13 Jun 2021, 20:07 | 687,456 | Taproot locked in, activation set for block 709,632 |
| 14 Nov 2021, 05:15 | 709,632 | Taproot active (minimum activation height in BIP 341) |
The New York Agreement and the activation methods compared belong to a later lesson of this path on Bitcoin governance. The rest of this one is about what the rules do.
The problem SegWit fixed: a transaction ID others could change
A txid is the double SHA-256 hash of the transaction’s bytes. Before 2017 those bytes included the signatures, and a signature could be rewritten without being broken. ECDSA has a built-in symmetry: if (r, s) is a valid signature, so is (r, n – s), where n is the order of the curve. BIP 340 calls ECDSA signatures “inherently malleable” for that reason. Anyone who relayed an unconfirmed transaction could flip s, or add a harmless extra push to the scriptSig, and broadcast a version with a different txid that spent the same coins to the same places.
For a simple payment this was a nuisance: the money arrived, under an ID the sender did not expect. For anything built on top of an unconfirmed transaction it was fatal. A second transaction that spends an output of the first names it by txid. If the first gets mined under another ID, the second points at nothing and can never confirm. Contracts that need a refund transaction signed before the funding transaction is broadcast, the basis of payment channels, could not be built safely on that ground.
Developers tried to close the holes one at a time. BIP 66 made strict DER encoding a consensus rule in 2015, BIP 147 fixed the dummy element of OP_CHECKMULTISIG, and BIP 62, a broader list of malleability rules, ended up with the status Closed. Each patch covered one vector; none covered a signer who re-signs on purpose. SegWit took a different route. Its text states the result in one line:
“Segregated witness fixes the problem of transaction malleability fundamentally, which enables the building of unconfirmed transaction dependency chains in a trust-free manner.” BIP 141
The method is to leave the signatures out of the hash that names the transaction. In a SegWit spend the scriptSig is empty, the proof sits in the witness, and the txid is computed from a serialization without the witness. Changing a signature no longer changes the ID that other transactions point to. Bitcoin Core’s 0.13.1 release notes of 27 October 2016 describe this as solving “all known cases of unwanted transaction malleability”. Legacy inputs stayed as malleable as before, which is why a transaction that mixes them with SegWit inputs cannot count on keeping its ID.
What SegWit changed inside a transaction
A witness for each input, and a second ID for the whole
Lesson 1 showed the marker byte 0x00 and flag byte 0x01 that open a SegWit transaction, and the witness stacks placed after its outputs. BIP 144 defines that serialization and the rule old nodes rely on: they are never sent this form, only the transaction stripped of marker, flag and witness, which is exactly the form that hashes to the txid. The full form has its own hash, the wtxid.
The witness still has to be tied to the block, or a miner could blockchain, where users swap tokens directly from their own wallets without handing custody of their funds to a company.">swap it. BIP 141 does it through the coinbase: the wtxids of all transactions go into a second Merkle tree, and its root is written in an output of the coinbase transaction whose script starts with the bytes 0x6a24aa21a9ed, an OP_RETURN followed by the header aa21a9ed. A block explorer shows this output in any block that contains SegWit transactions, which since 2017 means nearly all of them. Old nodes read it as an ordinary data output.
Weight: the 4 million unit limit that replaced 1 MB
Taking signatures out of the old serialization also took them out of the old size count, and BIP 141 replaced the 1 MB limit with a limit on weight. A transaction’s weight is its base size (without witness) times three, plus its total size; a block may weigh at most 4,000,000 units. Non-witness bytes count four units each and witness bytes one. Virtual size is weight divided by four, rounded up, and it is what fee rates in sat/vB are applied to. Our guide to the mempool and transaction fees shows how wallets use vbytes to set a fee; lesson 1 works the formula through on a real 565-unit transaction.
The two blocks of the opening show the rule at work. In block 481,824, base size and total size are almost equal, so the block is a classic 1 MB block that also satisfies the new rule. In block 709,632, about 587,000 bytes are witness and about 824,000 are base data: three times the base plus the total gives 3,881,749. A block can only approach 4 MB if it is almost entirely witness, which ordinary payments are not. In its release notes for 0.13.1, Bitcoin Core estimated that the network could support “about 70% more transactions” if all wallets switched, a projection from the block contents of 2016, not a measured result.
BIP 141 lists this discount among the benefits of the design and describes it as effectively increasing the block size “to some extent”. Whether that was a fair answer to the demand for bigger blocks is the old dispute; the rule itself has not changed since 2017.
A new signature hash with the amount inside
BIP 143 changed what a SegWit signature commits to, and it fixed two old problems while doing so. In legacy scripts each signature check rehashes most of the transaction, so the hashing work grows with the square of the number of signature operations. BIP 143 gives the worst case: “a 1MB transaction with 5569 sigops may take 25 seconds to verify”, against about 2 seconds for a normal 1 MB block on a 2015 computer. The new algorithm hashes the shared parts once and reuses them, so the cost grows linearly.
The second fix is for hardware wallets. A legacy signature does not commit to the amount of the coin being spent, so an offline device had to be fed the full previous transaction to know what it was signing, and the fee. Under BIP 143 every signature commits to the amount of its input. If someone lies to the device about that amount, the signature it produces is simply invalid.
Version 0 programs: P2WPKH, P2WSH and the wrapped form
Version 0 has two programs, told apart by length. A 20-byte program is the hash of a public key (P2WPKH): the witness must hold a signature and that key. A 32-byte program is the SHA-256 hash of a script (P2WSH): the witness holds the inputs and the script itself, which may be up to 10,000 bytes. BIP 141 explains the longer 32-byte hash, against 20 bytes in P2SH, as protection against collision attacks, since 2 to the power 80 operations was no longer out of reach.
In 2017 most wallets and exchanges could not yet pay to the new outputs, so BIP 141 also defined a nested form: the witness program is placed inside an ordinary P2SH output, an address starting with 3. The sender sees a familiar address; the receiver gets most of the witness discount when spending. This “nested” or “wrapped” SegWit is one reason the P2SH share in the adoption table below stayed high for years after 2017.
Native version 0 outputs got a new address encoding, bech32, defined in BIP 173, with addresses starting bc1q. Taproot outputs use bech32m (BIP 350) and start bc1p. Lengths, checksums and the reason bech32m was needed are in our guide to crypto addresses.
Why the malleability fix mattered more than the discount
Fee savings were the selling point for users, but the fix of malleability was what developers waited for. A Lightning channel is opened by a funding transaction that locks coins in a 2-of-2 multisig output, and each party holds signed transactions that spend that output before it is even confirmed. Those pre-signed spends refer to the funding transaction by txid. With a malleable txid, the counterparty or any relaying node could have made them useless and left the coins stuck.
Once SegWit was active, the ID of a transaction whose inputs are all SegWit is fixed the moment it is signed. Our guide to layer 1 and layer 2 networks gives the overview of Lightning; the next lesson in this path covers it in depth, channels, routing and limits included. Taproot came back to Lightning later: Bitcoin Optech recorded that LND v0.17.0-beta shipped experimental Taproot and MuSig2 channels in 2023, and that Core Lightning made Pay-to-Taproot the default for anchor spends and unilateral closes in November 2024.
Taproot: three BIPs and one new output
Taproot is the common name for three documents by Pieter Wuille, Jonas Nick and Anthony Towns (Tim Ruffing instead of Towns for BIP 340): Schnorr signatures (BIP 340), the Taproot output and its spending rules (BIP 341), and the script rules inside it, tapscript (BIP 342). Their output, P2TR, is a witness program of version 1 with 32 bytes of data, and those 32 bytes are a public key, not a hash.
Schnorr signatures, checked with one equation
Our guide to cryptography introduces Schnorr signatures in a few lines: same secp256k1 curve as ECDSA, 32-byte public keys, 64-byte signatures. The verification rule shows why they matter. A signature is a point R and a number s; it is valid for key P and message m when s times the generator G equals R plus hash(R, P, m) times P. Every term is a sum of points, with no inversion or division inside, unlike ECDSA.
That form is linear: keys and partial signatures of several people can be added into one key and one signature. BIP 340 also describes batch verification, many signatures checked together faster than one by one, and non-malleability: a valid signature cannot be rewritten into another valid one, so the (r, n – s) trick of ECDSA disappears. The fixed 64-byte encoding replaces DER, whose variable length had caused consensus problems before BIP 66.
The tweaked key: a script tree folded into a public key
A Taproot output key Q is built from an internal key P and an optional set of scripts. The scripts are the leaves of a Merkle tree; its root, call it k, is hashed with P into a number t, and the output key is Q = P + tG. Anyone who knows P and k can check that Q commits to them. Anyone who sees only Q sees a public key like any other. When there are no scripts, BIP 341 still recommends tweaking the key with a hash of P alone, so that no co-owner can slip in a script path the others do not know about.
Key path: one signature, nothing else shown
The first way to spend is the key path: a single 64-byte Schnorr signature valid for Q, or 65 bytes if a non-default sighash flag is used. Nothing else goes in the witness. The internal key, the scripts and even the fact that scripts existed stay off the chain. A single person with a single key produces exactly this. So does a group that combined its keys into one with MuSig2, the multi-signature protocol published as BIP 327, where each signer contributes a partial signature and the result is one ordinary-looking signature.
BIP 341 also changed the signature hash again. A Taproot signature commits to the amounts and the output scripts of all inputs being spent, rather than its own alone, which BIP 341 says “eliminates the possibility to lie to offline signing devices about the fee of a transaction”. BIP 143 had protected one input’s amount; this covers the whole transaction.
Script path: reveal one branch of the tree
The second way is the script path, used when the parties cannot or will not all sign. The spender reveals one leaf script, the inputs that satisfy it and a control block of 33 + 32m bytes: one byte for the leaf version and the parity of Q, the 32-byte internal key, then m hashes of 32 bytes that prove the leaf sits in the tree, m being at most 128. Nodes recompute the root, check that P tweaked with it gives Q, then run the script. Only the branch used is published; the other leaves stay hidden.
This is the idea long discussed as MAST, Merkelized abstract syntax trees, delivered as part of Taproot. A contract with ten possible exits used to put all ten in a P2SH or P2WSH script and reveal all of them at the spend. Under Taproot it reveals one, with a proof whose size grows with the depth of the tree, not with the number of leaves.
Tapscript: what changed inside the scripts
Scripts run under leaf version 0xc0 follow BIP 342. OP_CHECKSIG and OP_CHECKSIGVERIFY now check Schnorr signatures with 32-byte keys. OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY are disabled, because they cannot be batch-verified: they try keys in order until signatures match. A k-of-n policy is written instead with the new OP_CHECKSIGADD (opcode 186), which checks one key and adds 1 to a counter when the signature is valid; the script ends by comparing the counter with k. The off-by-one dummy element of the old opcode, covered in lesson 1, is gone with it.
Two limits were dropped. The 10,000-byte script size limit does not apply in tapscript, and neither does the limit of 201 non-push opcodes: BIP 342 says the size is “only implicitly bounded by the block weight limit”. Its reason is about verification cost, since the script is no longer hashed again for every signature check. Signature checks get their own budget instead: 50 plus the size of the input’s witness, with each executed signature check costing 50. The limit of 520 bytes per stack element and of 1,000 elements on the stack stays.
BIP 342 also renamed a list of unused opcodes OP_SUCCESSx: a script containing one is valid unconditionally. That sounds reckless, but it is the same backdoor as the witness versions, one level down. A future soft fork can give one of those opcodes a meaning and make some of those scripts invalid, which only tightens the rules. Unknown leaf versions and public key types are kept free for the same purpose.
A worked example: a 2-of-3 savings vault with a recovery path
An illustrative arrangement shows the two paths together. Three keys belong to Alice, Bob and a backup service; any two may spend, and after a year without movement a separate recovery key may sweep the coins alone. The internal key is a MuSig2 aggregate of Alice’s and Bob’s keys, the pair expected to sign most of the time. The tree has three leaves: Alice plus the backup, Bob plus the backup, and the recovery key behind a relative timelock of 52,560 blocks (about a year), the OP_CHECKSEQUENCEVERIFY lock explained in lesson 1.
On a normal day Alice and Bob sign together through the key path. The chain sees one 64-byte signature, an input of about 57.5 vbytes, and nothing that tells it a vault, a backup service or a recovery plan exist. If Bob loses his phone, Alice and the backup spend through their leaf: the chain sees that one leaf with its two keys and two signatures, plus a control block with one or two hashes, and still nothing about the recovery branch. In P2WSH the same policy would put every key and the whole timelock condition on the chain at every spend.
Legacy, SegWit and Taproot side by side
The size figures are those of the Bitcoin Optech transaction size calculator, which assumes 72-byte ECDSA signatures (the upper bound; low-R signing makes them 71) and 33-byte compressed keys. The nested SegWit input is Coindaro’s sum from the same field sizes: 64 non-witness bytes and a 108-byte witness, so 64 + 27 = 91 vbytes.
| Legacy P2PKH | Nested SegWit (P2SH-P2WPKH) | Native SegWit P2WPKH | Taproot P2TR | |
|---|---|---|---|---|
| Address starts with | 1 | 3 | bc1q | bc1p |
| Witness version | none | 0, inside P2SH | 0 | 1 |
| Signature | ECDSA, DER, 71-72 bytes | ECDSA | ECDSA | Schnorr, 64-65 bytes |
| Input size (single key) | 148 vB | about 91 vB | 68 vB | 57.5 vB (key path) |
| Output size | 34 vB | 32 vB | 31 vB | 43 vB |
| Signature data in txid | yes (malleable) | no | no | no |
| What a spend reveals | key and signature | key, signature, wrapper script | key and signature | one signature (key path) or one script leaf |
| Multisig input example | P2SH 2-of-3: 297 vB | not computed | P2WSH 2-of-3: 104.5 vB | 57.5 vB if the signers aggregate keys |
A labelled example makes the trade-off concrete: one input, a payment output and a change output, all of the same type. With legacy P2PKH that is 10 + 148 + 2 x 34 = 226 vB. With P2WPKH it is 10.5 + 68 + 2 x 31 = 140.5 vB. With P2TR it is 10.5 + 57.5 + 2 x 43 = 154 vB. At 3 sat/vB, the fastest rate shown by mempool.space at 10:23 UTC on 9 November 2026, those come to 678, about 422 and 462 satoshis.
So a single-key Taproot payment of this shape is slightly larger than a native SegWit one: the output carries a 32-byte key instead of a 20-byte hash, and the sender pays for outputs. The receiver pays later for inputs, where Taproot is 10.5 vbytes lighter each time. A wallet that receives many small payments and spends them later saves on the way out; one that sends many payments with change outputs pays a little more on the way in. For shared custody the comparison flips clearly in Taproot’s favour, as the multisig row shows, but only when the signers can run MuSig2 or a similar protocol.
What changed for fees and privacy, and what did not
The fee gain of SegWit came from the witness discount and from smaller scripts, and it is large: about 38 percent fewer vbytes for the one-input example above. Taproot’s gain is small for single keys and large for policies with several keys or conditions. Neither changes the fee market itself: a fee rate is still set by competition for block space, as described in the mempool guide.
Privacy improved in one precise way. Before Taproot a spend showed what kind of lock it opened, single key, multisig, timelock or hash lock, and often all its conditions. A Taproot key-path spend looks the same for a person, a company with a three-key policy and a Lightning channel closed cooperatively. That only works if many people use the same output type; a rare type is a fingerprint in itself.
What Taproot did not change matters as much. Amounts are public. Addresses are public, and reusing one still links payments. A transaction with several inputs still suggests a common owner, the heuristic explained in our guide to the UTXO and account models, because Taproot did not include cross-input signature aggregation: each input still carries its own signature. BIP 341 says that idea was left for later because it “interacts in complex ways with upgrade mechanisms”. A script-path spend also reveals that a script existed, and which one was used.
Who uses SegWit and Taproot: dated snapshots
No single official series of adoption exists, and the result depends on what is counted: transactions, inputs, outputs or vbytes. The table is Coindaro’s count from raw blocks read from mempool.space on 9 November 2026, and each row is a sample, not an average: four blocks (every third block from the first one listed, around 00:00 UTC on that date), every transaction parsed, every output classified by its script. “With witness” counts transactions that carry any witness data, so from 2021 it includes Taproot. Output shares are of all outputs created, data outputs included. The last column is the share of inputs that look like a Taproot key-path spend, a single witness item of 64 or 65 bytes.
| Sample date | Blocks | Tx with witness | P2PKH outputs | P2SH outputs | P2WPKH outputs | P2TR outputs | OP_RETURN outputs | Taproot key-path inputs |
|---|---|---|---|---|---|---|---|---|
| 1 Aug 2017 | 478,478 to 478,487 | 0.0% | 84.0% | 14.8% | 0% | n/a | 1.1% | n/a |
| 1 Nov 2017 | 492,557 to 492,566 | 9.2% | 84.4% | 15.3% | 0% | n/a | 0.2% | n/a |
| 1 Nov 2018 | 548,213 to 548,222 | 36.4% | 53.2% | 35.2% | 4.3% | n/a | 7.1% | n/a |
| 1 Nov 2019 | 601,841 to 601,850 | 46.7% | 48.8% | 36.1% | 10.4% | n/a | 3.6% | n/a |
| 1 Nov 2020 | 654,932 to 654,941 | 39.0% | 43.6% | 43.4% | 11.1% | n/a | 0.5% | n/a |
| 1 Nov 2021 | 707,633 to 707,642 | 81.1% | 20.9% | 44.7% | 30.3% | n/a | 0.7% | n/a |
| 1 Nov 2022 | 761,191 to 761,200 | 81.0% | 20.5% | 38.8% | 35.6% | 0.2% | 0.4% | 0.5% |
| 1 Nov 2023 | 814,748 to 814,757 | 95.3% | 9.4% | 16.0% | 38.1% | 30.0% | 4.2% | 13.6% |
| 1 Nov 2024 | 868,326 to 868,335 | 98.3% | 4.9% | 4.8% | 41.2% | 23.8% | 24.2% | 20.0% |
| 1 Nov 2025 | 921,682 to 921,691 | 96.8% | 5.0% | 3.7% | 46.2% | 22.3% | 20.8% | 7.3% |
| 1 Nov 2026 | 974,043 to 974,052 | 98.9% | 1.9% | 1.7% | 54.3% | 3.7% | 37.4% | 4.7% |
Four blocks are a sample, not a trend line, and the Taproot columns prove it: 30.0 percent of outputs in November 2023, 3.7 percent three years later, with swings in between that track waves of inscriptions and of data outputs more than any steady choice by wallets. What the series does show is the shape. Legacy P2PKH outputs went from over 80 percent to 1.9 percent of all outputs in the November 2026 sample. SegWit went from nothing to almost every transaction in the sampled blocks within about six years, with a slow climb until 2020 and a jump by November 2021. Native SegWit v0 keys are now the dominant lock, and Taproot is a minority type whose share depends on what else is happening in blocks.
A wider sample gives a steadier picture. Over the 144 consecutive blocks 975,014 to 975,157, stamped between 02:15 UTC on 8 November and 09:30 UTC on 9 November 2026, Coindaro counted 537,583 transactions, of which 89.9 percent carried witness data. Leaving data outputs aside, the 1,041,956 spendable outputs created in those blocks were 69.6 percent P2WPKH, 10.5 percent P2TR, 6.8 percent P2PKH, 5.9 percent P2SH and 3.4 percent P2WSH. Of 1.2 million inputs, 9.5 percent looked like Taproot key-path spends and 13.2 percent were in transactions with no witness at all. One block in that window, 975,157, held about 7,959 transactions that almost all paired a native SegWit output with a data output, enough on its own to move the day’s output shares.
How wallets and nodes caught up
Rules active in a block do not mean wallets use them. Bitcoin Core shipped SegWit validation in 0.13.1 on 27 October 2016, ten months before activation, but its own wallet made native SegWit the default only with 0.20.0, published on 3 June 2020, whose notes say the wallet “now by default uses bech32 addresses when using RPC, and creates native segwit change outputs”. The slow climb of the witness column between 2018 and 2020 fits that pace, with nested addresses as the bridge. Taproot repeated the lag: paying a bc1p address needs software that knows bech32m, which the address guide dates for the first wallets to 2021, and multi-party tools came later still, since MuSig2 signers must swap nonces in rounds before a signature exists.
How Taproot ended up storing pictures: the Ordinals link
Taproot’s designers wrote about signature costs and privacy, not about storing files. Yet the inscription waves that move the Taproot column above rely on exactly two of its features. The Ordinals documentation states the mechanism: “Inscription content is entirely on-chain, stored in taproot script-path spend scripts.” The data sits inside an envelope, OP_FALSE OP_IF followed by the content and OP_ENDIF, a branch that never runs, so the script around it still works normally.
Two tapscript rules make that practical. With the 10,000-byte script limit gone, a leaf script can be as large as the block weight allows, and since the script is revealed in the witness, every byte of it is counted at one weight unit instead of four. The 520-byte limit per stack element still applies, so content is cut into pushes of at most 520 bytes. Because a script path can only be used by spending an existing Taproot output, an inscription takes two transactions: a commit that creates the output, and a reveal that spends it and puts the content on the chain.
Whether this is a legitimate use of block space or spam is a dispute this lesson does not settle. It led to the 2026 attempt to limit such data by soft fork, BIP-110, told in the forks guide, and it is one of the debates of the governance lesson later in this path. Ordinals, BRC-20 tokens and Runes get their own lesson after the one on running a node.
Taproot’s exposed keys and the quantum debate
A P2PKH or P2WPKH output stores a hash of the public key; the key itself appears only when the coin is spent. A Taproot output stores the key, tweaked but usable, in the output from the day the coin arrives. If a machine able to solve the elliptic-curve discrete logarithm ever existed, every unspent Taproot output would be exposed for as long as it sits on the chain.
BIP 341 discusses this in a footnote and plays it down. It argues that hiding a key behind a hash offers protection that is “very weak at best”, since keys are revealed in the mempool at every spend and a large share of coins already sit behind exposed keys, and that real resistance needs different cryptography. The authors of BIP 360 draw another conclusion. Their proposal, assigned on 18 December 2024 and still a Draft (version 0.12.1 on 9 November 2026), adds a new output type, Pay-to-Merkle-Root, that keeps Taproot’s script trees and drops the key path. It admits its limit in its own words: “Bitcoin outputs are generally vulnerable to short exposure attacks, as most Bitcoin transactions require revealing the associated public key when spending.”
Estimates of when such a machine could exist vary widely and none is settled. Coindaro covered one of the recent ones, the Alice & Bob paper on cat qubits and Bitcoin’s curve, whose figures rest on assumptions no existing machine meets. BIP 360 is a proposal, not a rule, and the list of open proposals is for the governance lesson.
Choosing an address type in your wallet
Many wallets let you pick native SegWit (bc1q) or Taproot (bc1p) for receiving, and some still offer nested (3…) and legacy (1…) types. All four remain valid and spendable; no rule retires them. The size table gives the trade-off on fees and the previous section the one cost Taproot adds, a key on the chain while the coins wait. One more check belongs before you switch: make sure the people or services that pay you can send to the type you pick. A sender that rejects a bc1p address is usually running software without bech32m, not facing a typo.
Moving old coins to a newer address type is a transaction to yourself, and it pays a fee like any other. For readers in the United States, the IRS digital assets page lists a transfer from one wallet or account you own or control to another as a case where the digital-asset question is answered “No”, unless you paid the transaction fee with digital assets: “This would be a digital asset transaction.” Our guide to crypto taxes in the United States explains how that fee is treated and what records to keep.
What to remember about SegWit and Taproot
- SegWit (2017) and Taproot (2021) are soft forks that both use witness versions, outputs that old nodes treat as anyone-can-spend.
- SegWit moved signatures out of the txid, which ended third-party malleability for SegWit spends and made payment channels safe to build.
- Taproot puts a tweaked public key in the output; it can be spent with one Schnorr signature or by revealing one script from a hidden tree.
- A single-key Taproot output is larger than a native SegWit one and its input smaller; the gain is clearest with shared keys.
- Coindaro’s block samples show witness data in about nine transactions in ten or more by 2026, and Taproot as a minority type whose share swings with inscription waves.
The next lesson of this path turns to the Lightning Network, the payment-channel system that depends on the fixed transaction IDs SegWit brought.
