SegWit and Taproot under the hood

After this lesson you can: explain what SegWit and Taproot changed and why fees differ.

SegWit (BIP 141, activated August 2017)

The witness (signatures and unlocking data) was moved out of the part of the transaction that is hashed into the txid. Two consequences:

1. Malleability fixed. A third party could previously re-encode a signature and change a txid without invalidating the transaction, which broke anything that pre-signed chains of transactions. Lightning needed this fix.
2. Block weight. The old 1 MB size limit became a 4,000,000 weight unit limit, where non-witness bytes count 4 and witness bytes count 1. Blocks with many SegWit transactions reach 1.8 to 2.5 MB; a block of only witness data could reach 4 MB. Fees are quoted per virtual byte (weight ÷ 4).

Old nodes see SegWit transactions as "anyone can spend" outputs and accept them, which is how it was a soft fork. The activation fight, settled by user-enforced BIP 148, is told in the governance course.

Taproot (BIPs 340, 341, 342, activated November 2021)

• Schnorr signatures replace ECDSA for Taproot outputs.
• P2TR outputs pay to a public key that has been tweaked with the root of a Merkle tree of scripts (MAST). To spend, either sign with the tweaked key (the key path, indistinguishable from any single-sig spend) or reveal one script from the tree plus a proof it was committed (the script path). Unused scripts stay hidden forever.
• Tapscript updates the scripting rules inside Taproot and reserves room for future opcodes.

For a 2-of-3 multisig, the key path can be a MuSig aggregate of all three; the script path holds fallbacks. On-chain, a cooperative spend looks like one key and one 64-byte signature. Lightning channels, vaults and inheritance scripts all benefit.

Adoption

Nearly all transactions use SegWit; Taproot adoption grew more slowly and got an unexpected push from inscriptions in 2023, which store data in Taproot witnesses.