SegWit is one of the most consequential upgrades in Bitcoin's history, and yet most people who use Bitcoin daily interact with its effects without knowing it. Lower transaction fees on native SegWit wallets, the existence of the Lightning Network, and addresses that start with "bc1" - all of these trace back to SegWit. Understanding what it changed, and why it mattered, gives a clearer picture of how Bitcoin evolves through decentralized consensus.
Before SegWit, every Bitcoin transaction was stored as a single block of data: inputs, outputs, and the digital signatures (called "witness" data) proving that the sender had the right to spend the coins. All of this counted equally toward the 1 MB block size limit.
SegWit - short for Segregated Witness - changed the layout. It moved the witness data (signatures) out of the traditional transaction data structure and into a separate "witness" section of the block. This witness section is not subject to the old 1 MB limit.
To measure how full a block is under SegWit, Bitcoin switched from counting raw bytes to counting block weight. Each byte of non-witness transaction data counts as 4 weight units. Each byte of witness data counts as only 1 weight unit. The maximum block weight is 4 million weight units - which is equivalent to the old 1 MB limit for non-SegWit data, but can accommodate more data when that data is witness information.
The practical effect: a block can hold significantly more SegWit transactions than legacy transactions. In practice, SegWit blocks average around 1.2 to 1.8 MB of actual data without ever changing the nominal 1 MB block size limit.
Before SegWit, Bitcoin had a subtle but serious vulnerability called transaction malleability. The transaction ID (TXID) of an unconfirmed transaction was a hash of the entire transaction data, including the signatures. Because signature data could be slightly modified (while remaining mathematically valid) by a third party, the TXID of a transaction could change before it was confirmed.
This created a problem: if the TXID could change, software watching for that specific TXID would not recognize the transaction when it confirmed under the modified ID. This was exploited in some exchange hacks to trigger duplicate withdrawals by claiming a transaction had not been received when in fact it had - just under a different TXID.
SegWit fixed this by computing the TXID from only the non-witness portion of the transaction data. Signatures are excluded from the TXID calculation, so no third-party manipulation of the witness data can change the TXID. The transaction ID becomes a stable, reliable identifier from the moment the transaction is broadcast.
Fixing transaction malleability was not just a security patch - it was a prerequisite for building reliable second-layer protocols. The Lightning Network requires chaining multiple unconfirmed transactions together, where each transaction references the TXID of an earlier one. This only works safely if those TXIDs cannot be changed by a third party.
The Lightning Network is a payment channel system built on top of Bitcoin. It allows two parties to open a channel, make many payments off-chain at near-zero fees, and then close the channel with a final settlement recorded on the Bitcoin blockchain. This scales Bitcoin's payment capacity dramatically.
Lightning requires constructing multi-transaction arrangements where each transaction is pre-signed but not yet broadcast. These "commitment transactions" must reference each other by TXID. Before SegWit, transaction malleability meant any of those pre-signed TXIDs could be changed, breaking the whole arrangement. The Lightning Network as designed was not safely deployable on Bitcoin without SegWit's malleability fix.
SegWit's activation in August 2017 was the technical green light that made Lightning Network development practical. The Lightning Network mainnet launched in March 2018 - less than seven months later.
SegWit introduced a new address format called bech32. Native SegWit addresses are easily recognizable because they start with bc1 (lowercase). They are sometimes called "P2WPKH" (Pay to Witness Public Key Hash) or "P2WSH" (Pay to Witness Script Hash) addresses.
Native SegWit addresses offer several advantages over legacy formats:
A later improvement, bech32m, was introduced with Taproot (2021) for addresses starting with "bc1p". Taproot addresses are sometimes called "native SegWit v1."
The fee savings from native SegWit are real and measurable. Spending from a native SegWit address typically costs 30-40% less in fees than spending from a legacy address under the same network conditions. For users who transact frequently, this adds up significantly over time.
SegWit also demonstrated something important about Bitcoin's governance: major protocol upgrades are possible without a hard fork. By deploying SegWit as a backward-compatible soft fork, the network avoided splitting. Old nodes that never upgraded still process transactions and remain valid participants in the network. Miners who signaled for SegWit did so by majority vote, not by forcing an upgrade on holdouts.
Today, native SegWit adoption sits above 80% of all Bitcoin transactions. The fee and efficiency benefits have driven organic adoption, and most modern wallets default to creating bech32 addresses. SegWit's architecture also laid the groundwork for Taproot, Bitcoin's next major upgrade, which builds on the same witness structure to add privacy and scripting improvements.
Bitcoin From Scratch covers SegWit, the Lightning Network, transaction structure, and the full technical picture - through 34 3D animated lessons designed for anyone starting from zero.
Get Bitcoin From Scratch - $97SegWit stands for Segregated Witness. It is a Bitcoin protocol upgrade that changed how transaction data is structured inside a block. The "witness" data - the digital signatures that prove ownership - was moved into a separate part of the block structure, outside the traditional block size limit. This allowed more transactions to fit per block and fixed a technical bug called transaction malleability.
SegWit activated on the Bitcoin mainnet at block 481,824 on August 24, 2017. It was deployed as a soft fork using BIP141, BIP143, and BIP148. Miner signaling for SegWit reached the required threshold and locked in before the August activation.
SegWit solved two main problems. First, it increased effective block capacity without raising the 1 MB block size limit, by measuring transaction weight instead of raw byte size and discounting witness data. Second, it fixed transaction malleability - a bug that allowed third parties to alter a transaction's ID before it confirmed, without changing what the transaction did. Fixing malleability was essential for building reliable second-layer payment systems like the Lightning Network.
A bech32 address is a native SegWit Bitcoin address format. These addresses start with "bc1" (lowercase) and are sometimes called "native SegWit" or "P2WPKH" addresses. They are more compact than legacy addresses, use lowercase only (reducing typo errors), include built-in error detection, and produce lower transaction fees because their input data is weighted less under SegWit's block weight rules.
No. SegWit does not change Bitcoin's 21 million coin supply cap. It only changed how transaction data is structured and measured within blocks. The issuance schedule, the halving cycle, and the hard cap of 21 million Bitcoin are defined by entirely separate parts of the protocol and were untouched by SegWit.