What Is Segregated Witness (SegWit)?
Segregated Witness (SegWit) is a 2017 Bitcoin protocol upgrade that moves transaction signature data — the "witness" — out of the main transaction body into a separate, discounted section. Because signatures consume roughly 60% of a transaction's bytes, separating them frees block space and raises effective capacity without a hard fork. SegWit was deployed as a backward-compatible soft fork and activated on 23 August 2017 after 95% of miners signaled support. Beyond capacity, it permanently fixes transaction malleability, upgrades multisig hashing to 256-bit, and makes signature verification scale linearly. Its malleability fix is what made the Lightning Network and later Taproot upgrade possible.
Segregated Witness, almost always shortened to SegWit, is a 2017 upgrade to the Bitcoin protocol that restructures how transaction data is stored. It moves the cryptographic signature (the “witness”) out of the main transaction body and into a separate, segregated area. Because signatures historically consumed roughly 60% of a transaction's bytes, separating them frees space inside each block, raises effective capacity, and removes a long-standing bug called transaction malleability. SegWit was deployed as a backward-compatible soft fork and activated on the Bitcoin mainnet on 23 August 2017.
Why SegWit Was Created
By 2016–2017 the Bitcoin network was straining against a hard 1 MB block size limit. Blocks filled up, mempools backed up, confirmation times stretched out, and fees spiked during peak demand. The community had spent more than a year debating how to scale, with discussions crystallizing at the Bitcoin Scaling Conference in Hong Kong. SegWit, first proposed by core developer Pieter Wuille in October 2016, offered a way to increase throughput without the contentious step of simply enlarging the block size through a hard fork. If you want a deeper breakdown of how these upgrade paths differ, see our explainer on soft forks versus hard forks.
The core insight: not all transaction data needs to live in the same place. Signature data is only required to validate a transaction once — after that, it does not need to be re-hashed alongside the rest of the data. By pulling it aside, SegWit unlocked several improvements at once.
How SegWit Works Technically
Every Bitcoin transaction contains two key script components: the scriptSig, which holds the unlocking signature data, and the scriptPubKey, which describes the locking condition tied to the recipient's public key. In legacy transactions both are hashed together to produce the transaction ID (TXID).
SegWit changes this by removing the witness (signature) data from the part of the transaction that determines the TXID. The witness is committed separately, so altering a signature can no longer change the transaction's identifier. Because old nodes still see SegWit transactions as valid — they simply ignore the witness structure they don't understand — the change is backward compatible and ships as a soft fork. For activation, the original proposal required at least 95% of miners to signal support, a threshold met in mid-2017.
SegWit also introduced the concept of block weight and a measurement unit called the virtual byte (vByte), replacing a strict byte-based size cap with a weight limit of 4 million weight units. Witness data is discounted, which is why SegWit blocks can effectively hold more transactions than the old 1 MB ceiling allowed.
Legacy vs SegWit: At a Glance
| Property | Legacy (pre-SegWit) | SegWit |
|---|---|---|
| Signature location | Inside main transaction body | Separated into witness area |
| Block capacity measure | 1 MB hard limit | 4M weight units (≈ up to ~2–4 MB effective) |
| Transaction malleability | Possible | Fixed |
| Multisig hash | 160-bit (P2SH) | 256-bit (SHA-256) |
| SigHash scaling | Quadratic | Linear |
| Lightning Network ready | No | Yes |
The Main Benefits of SegWit
More Transactions Per Block
By discounting witness data, SegWit lets more economic transactions fit within the same consensus weight budget. In practice this raised effective throughput without a hard fork, easing the capacity pressure that drove fees and delays in 2017.
Transaction Malleability Fix
Malleability occurs when a third-party node alters the unlocking data of an unconfirmed transaction, changing its TXID before it propagates further. For users tracking payments this was confusing; for developers it was a blocker. By excluding signatures from the TXID calculation, SegWit makes the identifier stable — which is precisely the property needed for second-layer protocols.
Stronger Multisig Security
Legacy multi-signature scripts used Pay-to-Script-Hash (P2SH) built on a 160-bit hash. SegWit upgrades native script hashing to a 256-bit SHA-256 function, dramatically shrinking the probability of a brute-force collision and improving security for multisig and smart contract spending.
Linear SigHash Scaling
In the legacy model, the amount of data hashed for signatures scaled quadratically: doubling a transaction's size roughly doubled both the number of signature operations and the data hashed for each. SegWit re-engineers the signature hash so each byte is hashed only once, turning verification into a linear function. That makes large transactions — and larger blocks — far safer to validate.
A Worked Fee Example
Suppose a wallet sends a simple transaction. Roughly speaking, the signature accounts for about 60% of its raw bytes. Imagine a legacy transaction measured at 250 bytes:
- Legacy: all 250 bytes count toward the block at full weight. At a fee rate of 20 sats/byte, the fee is 250 × 20 = 5,000 sats.
- SegWit: the ~150 bytes of witness data are discounted to one-quarter weight. Effective size ≈ 100 + (150 ÷ 4) ≈ 137.5 vBytes. At the same 20 sats/vByte rate, the fee is ≈ 137.5 × 20 ≈ 2,750 sats — around a 45% saving.
The exact numbers depend on the transaction type and current fee market, but the principle holds: SegWit (and especially native bech32 addresses starting with `bc1`) is cheaper to spend.
COINOTAG Perspective: Why SegWit Still Matters
SegWit is easy to file away as a one-time 2017 event, but its real legacy is structural. By making transaction IDs immutable, it laid the groundwork for the Layer 2 Lightning Network, which depends on chains of unconfirmed transactions that cannot be malleated. It also paved the way for the 2021 Taproot upgrade, which builds on SegWit's versioning system. In our view, SegWit is the clearest example of how Bitcoin evolves: conservative, backward-compatible soft forks that add capability without forcing the network into a contentious split. Adoption has climbed steadily over the years, and today the large majority of Bitcoin transactions are SegWit-based — a quiet but decisive win for on-chain efficiency.
Risks and Pitfalls to Know
- Wallet compatibility: Some very old wallets or services may not support sending to native SegWit (bech32) addresses. Always confirm the recipient can receive `bc1` addresses before relying on the lowest fees.
- Address-format confusion: Bitcoin now has legacy (`1...`), P2SH-wrapped SegWit (`3...`), and native SegWit (`bc1...`) formats. Sending to the wrong format does not lose funds, but it can mean higher fees than necessary.
- Not a magic scaling fix: SegWit raised effective capacity but did not make Bitcoin infinitely scalable. True high-throughput payments still rely on Layer 2 solutions like Lightning.
- Opt-in, not automatic: Users only capture SegWit's fee savings if their wallet actually generates and spends from SegWit addresses.
Key Takeaways
Segregated Witness separates signature data from the core of a Bitcoin transaction to boost block capacity, eliminate transaction malleability, strengthen multisig security, and enable linear signature verification. Activated on 23 August 2017 via a backward-compatible soft fork, it remains foundational — the bridge between base-layer Bitcoin and the Lightning Network era.