SegWit explained: what Segregated Witness changed in Bitcoin, and how it activated in 2017

SegWit moved signatures out of the part of a transaction that gets its ID

A Bitcoin transaction has two jobs. It says which coins are being spent and where they are going, and it proves the spender is allowed to do that, usually with a digital signature. Before SegWit, both parts lived in one blob of data, and the transaction ID (the txid, the hash that wallets and explorers use to refer to a transaction) was computed over all of it, signatures included.

BIP141, the proposal written by Eric Lombrozo, Johnson Lau and Pieter Wuille, changed that. The signature data, which the proposal calls the “witness,” is carried in a separate structure that is committed to the block through the coinbase transaction but is not part of the txid. A transaction now has two identifiers: the familiar txid, computed without the witness, and a new wtxid that includes it.

The upgrade was designed as a soft fork, meaning the new rules are stricter than the old ones rather than incompatible with them. A node running older software still sees SegWit blocks as valid and keeps following the chain; it simply does not check the witness data itself. Bitcoin Core’s release notes for version 0.13.1 describe it as allowing software to “separate (segregate) transaction signatures (witnesses) from the part of the data in a transaction that is covered by the txid.” If the distinction is new to you, our soft forks and hard forks article explains it.

The malleability fix has specific signing conditions

Signatures have a quirk. With the signature scheme Bitcoin used, a third party who sees a transaction can tweak the signature into a different but still valid form without knowing the private key. The transaction still spends the same coins to the same places, but its txid changes. This is called transaction malleability, and for years it was a nuisance at best and a real problem at worst, because any software that tracked a payment by its ID could lose sight of it.

Because the SegWit txid no longer includes the signature, tweaking the signature no longer changes the ID. BIP141 puts it bluntly: “Nonintentional malleability becomes impossible.” The Bitcoin Core release notes say the change “solves all known cases of unwanted transaction malleability.”

That sounds like housekeeping, but it unlocked something bigger. Protocols that build chains of transactions before they are confirmed, where one transaction spends the output of another that has not reached the chain yet, need the earlier transaction’s ID to be stable. BIP141 lists the ability to create “unconfirmed transaction dependency chains without counterparty risk” as a direct benefit, and Bitcoin Core’s benefits page notes that with malleability fixed, the Lightning Network “is less complicated to implement.” The Lightning Network is the best-known thing built on that foundation.

Blocks are now measured in weight, not bytes

Before SegWit, a block could hold at most 1 MB of transaction data. BIP141 replaced that limit with a new measure called block weight. Every byte of witness data counts as one weight unit, and every other byte counts as four. The maximum block weight is 4,000,000 units. Put another way, weight equals the size of the block without witnesses times three, plus its full size.

The effect is a discount for signatures. A block made entirely of old-style transactions still fits about 1 MB, because every byte costs four units. A block full of SegWit transactions fits more, because a large share of each transaction is signature data that now costs a quarter as much. Bitcoin Core’s release notes estimated that “if all wallets switch to using segwit, the network will be able to support about 70% more transactions.” The benefits page describes the practical outcome as an effective limit “closer to 1.6 to 2 MB.”

So SegWit was a capacity increase, but a conditional one that depended on wallets adopting the new transaction format. That framing matters for understanding the politics. One camp saw a signature discount that fit within a soft fork as the responsible way to grow; another wanted a plain increase in the block size, which needs a hard fork. That argument, and the way it was eventually resolved, is the subject of our dossier on the block size war. This article stays with what the upgrade actually did.

Two quieter fixes: faster signature checks and safer hardware wallets

BIP143, a companion proposal by Johnson Lau and Pieter Wuille, changed how the data that a signature covers is assembled for SegWit transactions. Under the old method, checking every signature in a large transaction meant re-hashing almost the whole transaction for each one, so the work grew with the square of the transaction’s size. The proposal describes that growth as O(n²) and replaces it with a method that lets hashes be reused, so the work grows in a straight line instead.

The same proposal put the amount being spent into the data a signature covers. Before, a hardware wallet that signed offline could not be sure how much a given input was worth without being handed the entire previous transaction, which BIP143 calls “a big obstacle.” With the value committed in the signature, a device can be shown the amount and refuse to sign if it is wrong.

SegWit also introduced script versioning. Each witness program carries a version number, and Bitcoin Core’s release notes say this “makes it easy for future soft forks” to change the scripting language for users who opt in. That hook is exactly what Taproot used four years later.

Native version-0 SegWit addresses use bc1q

Native SegWit outputs needed a way to be written down, and BIP173, by Pieter Wuille and Greg Maxwell, supplied one. The format is called Bech32. A mainnet Bech32 address begins with the letters bc, then the digit 1, then a string of lowercase characters drawn from an alphabet that leaves out easily confused letters.

The proposal lists what was wrong with the older base58 addresses: their mixed case makes them “inconvenient to reliably write down, type on mobile keyboards, or read out loud,” they use a lot of space in QR codes, and their checksum “has no error-detection guarantees.” Bech32 addresses are one case throughout and use a checksum that is guaranteed to catch up to four mistyped characters.

Old addresses did not stop working, and you can still send to and from them. But a native SegWit address gets the full weight discount, so payments from it are cheaper. Our guide to Bitcoin address types walks through the formats side by side.

How it activated: nine months of signaling, then block 481,824

Bitcoin Core 0.13.1, released on 27 October 2016, shipped SegWit with its activation switch set. The mechanism was BIP9 version bits: miners could signal readiness by setting bit 1 in the blocks they produced, and if 95% of the blocks in a 2,016-block period signaled, the change would lock in and activate one period later. Tracking began with the first period after 15 November 2016.

For most of a year, the threshold was not met. What happened in between, including the user-activated soft fork proposal, the New York Agreement, BIP91 and the Bitcoin Cash split, is a story about who gets to decide what Bitcoin is, and our block size war dossier lays out the evidence step by step.

The outcome is not in dispute. Bitcoin Core’s own mainnet parameters record the activation height as 481,824, and a block explorer shows that block was mined by BTCC Pool on 24 August 2017 at 01:57 UTC with 1,866 transactions in it. From that block on, every node running SegWit rules has enforced them.

Use transaction weight to understand the fee comparison

BIP141 defines transaction weight as three times the base size plus the total size, and virtual size as weight divided by four, rounded up. In an illustrative transaction with a 100-byte base size and 300-byte total size, weight is 600 units and virtual size is 150 vbytes. This is an arithmetic example, not a typical transaction estimate.

That accounting explains why moving witness data can change the virtual size used in a fee comparison. It does not make every SegWit transaction a fixed percentage cheaper. Input and output types and the data actually included determine the sizes being compared.