If you’ve opened a Bitcoin wallet and been asked to choose between a “Legacy,” “SegWit,” or “Native SegWit” address with no explanation of what any of it means, that choice traces back to a single upgrade made in 2017.
SegWit, short for Segregated Witness, is a Bitcoin protocol upgrade activated in August 2017 that moves digital signature data out of the core transaction structure and into a separate field called the witness. That single architectural change reduced transaction fees, fixed a years-old security vulnerability called transaction malleability, and created the technical conditions for the Lightning Network and Taproot to exist.
This article covers what SegWit actually does, how the block weight system works, what the different address types mean for your fees, and the contentious political battle that nearly tore the Bitcoin network apart before it ever activated.
Manage your Bitcoin with the Bitcoin.com Wallet app.
Key Takeaways
- SegWit (Segregated Witness) is a Bitcoin protocol upgrade activated on August 24, 2017, formally specified as BIP 141 and proposed by Pieter Wuille, Eric Lombrozo, and Johnson Lau in December 2015.
- It separates digital signature data (the “witness”) from the main transaction body, fixing a security vulnerability called transaction malleability and making each transaction smaller.
- Block capacity is measured in weight units (WU) rather than bytes. Witness data costs 1 WU per byte vs 4 WU per byte for other data, giving SegWit transactions a 75% discount on signature size.
- Native SegWit (bc1q addresses) reduces a standard transaction from ~226 vbytes to ~141 vbytes, cutting fees by roughly 38% compared to legacy addresses.
- SegWit’s fixed-TXID guarantee was the technical precondition for the Lightning Network. Without it, payment channels could not be safely constructed.
- Its script versioning system enabled Taproot (SegWit V1, activated 2021) and provides a framework for future Bitcoin upgrades without hard forks.
- As of 2026, approximately 85% of Bitcoin transactions use SegWit. It is the network standard, not a new feature.
What Is SegWit?
SegWit, or Segregated Witness, is a change to Bitcoin’s transaction format that separates digital signatures, the cryptographic proof that you have the right to spend a coin, from the main transaction data and stores them in a separate structure called the witness. This makes each transaction smaller, allows more transactions to fit in each block, and eliminates a vulnerability that had made it impossible to safely build payment channels on top of Bitcoin.
The name breaks down simply: “segregated” means separated, and “witness” is the cryptographic term for the signature data that proves a transaction is valid. The witness answers the question “did the rightful owner authorize this?” while the rest of the transaction data answers “where are the funds going and for how much?”
The official BIP 141 header on GitHub, showing its three co-authors and December 2015 assignment date.
The upgrade was formally specified as Bitcoin Improvement Proposal 141 (BIP 141) and proposed by Bitcoin Core developers Pieter Wuille, Eric Lombrozo, and Johnson Lau at the Scaling Bitcoin conference in December 2015. It was activated on the Bitcoin mainnet on August 24, 2017, at block 481,824, as a soft fork, meaning it was backward compatible. Nodes that hadn’t upgraded could still validate the base transaction data; upgraded nodes saw the full picture including the witness.
As of 2026, approximately 85% of all Bitcoin transactions use SegWit. It is no longer a new feature but the standard.
The Problems SegWit Was Built to Solve
SegWit addressed two separate issues that had been limiting Bitcoin for years.
Transaction Malleability
Every Bitcoin transaction has a unique identifier called the TXID, a hash generated from the transaction data. Before SegWit, that hash was computed over the entire transaction, including the signature.
Here’s the problem: a cryptographic signature cannot sign itself. That left a small window where anyone relaying your transaction across the network could slightly modify the signature in a way that kept it mathematically valid but produced a different TXID. The funds still went to the right address and the transaction still went through, but the identifier had changed.
This doesn’t sound catastrophic for a simple payment. For protocols that chain multiple unconfirmed transactions together, it’s fatal. The Lightning Network, which works by creating a series of off-chain payment commitments that reference earlier transaction IDs, cannot function safely if any of those IDs can change before they confirm. A mutable TXID means the chain breaks, and funds can be stranded or stolen.
Transaction malleability also caused real-world damage before it was fixed. The Mt. Gox exchange cited it as a contributing factor in its 2014 collapse, though historians debate the extent to which it was the root cause versus an excuse for deeper mismanagement.
SegWit solved this by removing signatures from the TXID calculation entirely. The identifier is now computed only from the base transaction fields. Changing the signature no longer changes the transaction’s identity.
Block Congestion and Rising Fees
By 2016 and into 2017, Bitcoin was processing roughly 7 transactions per second. During demand spikes, transaction backlogs grew into the tens of thousands and fees climbed to $50 or more for a standard send. The problem was structural: Bitcoin’s blocks were capped at 1MB, and signatures made up roughly 65% of transaction size.
The obvious fix, raising the block size limit, required a hard fork, meaning all nodes would need to upgrade or be left on an incompatible chain. Hard forks are high-risk and contentious. SegWit found a way around this constraint entirely.
How SegWit Works
Separating Witness Data
In a legacy Bitcoin transaction, each input includes a ScriptSig field containing the spender’s signature and public key. In a SegWit transaction, the ScriptSig is left empty for SegWit inputs. The signature and public key move to a new witness field appended at the end of the transaction.
Two additional bytes, a marker (0x00) and a flag (0x01), tell SegWit-aware nodes that witness data follows. Nodes that predate SegWit simply see an empty ScriptSig and process the transaction as valid under the older “anyone can spend” interpretation, maintaining backward compatibility.
Block Weight Replaces Block Size
SegWit replaced the 1MB block size limit with a new metric: block weight, capped at 4 million weight units (WU).
The critical detail is in how bytes are counted:
- Every byte of non-witness transaction data costs 4 weight units
- Every byte of witness data costs only 1 weight unit
Because signatures are large and now live in the witness section, they cost one-quarter of what they used to in terms of block capacity. This is how SegWit increased the effective block size to around 1.7 to 2MB in practice without touching the 1MB rule that old nodes enforce. For a theoretical all-SegWit block, the maximum is 4MB, though this never occurs in practice because every block also contains non-witness data.
Virtual Bytes (vBytes): The Unit You See in Wallets
To keep fee rates comparable with legacy transactions, SegWit introduced virtual bytes (vbytes): weight units divided by 4. For legacy transactions, bytes and vbytes are identical. For SegWit transactions, vbytes are lower because the discounted witness data pulls the number down.
Wallet fees are quoted in satoshis per vbyte (sat/vB). A SegWit transaction with fewer vbytes pays less in fees at the same sat/vB rate. This is the mechanism behind the fee savings you see when using a bc1q address instead of a 1… address.
SegWit Address Types: Which One Should You Use?
SegWit introduced new address formats alongside its technical changes. The address type determines how your wallet encodes spending conditions, which affects your fees, your compatibility with other wallets, and how your transactions look on-chain.
Address Type Comparison
Address TypePrefixEncodingTypical Tx Size (1-in, 2-out)Fee Saving vs LegacyWallet SupportLegacy (P2PKH)1…Base58~226 vbytesBaselineUniversalNested SegWit (P2SH-P2WPKH)3…Base58~167 vbytes~26%Very broadNative SegWit (P2WPKH)bc1q… 42 charsBech32~141 vbytes~38%All modern walletsNative SegWit multisig (P2WSH)bc1q… 62 charsBech32Varies~32%+All modern walletsTaproot (P2TR)bc1p… 62 charsBech32m~154 vbytes~32%Most modern walletsAddress TypeLegacy (P2PKH)Prefix1…EncodingBase58Typical Tx Size (1-in, 2-out)~226 vbytesFee Saving vs LegacyBaselineWallet SupportUniversalAddress TypeNested SegWit (P2SH-P2WPKH)Prefix3…EncodingBase58Typical Tx Size (1-in, 2-out)~167 vbytesFee Saving vs Legacy~26%Wallet SupportVery broadAddress TypeNative SegWit (P2WPKH)Prefixbc1q… 42 charsEncodingBech32Typical Tx Size (1-in, 2-out)~141 vbytesFee Saving vs Legacy~38%Wallet SupportAll modern walletsAddress TypeNative SegWit multisig (P2WSH)Prefixbc1q… 62 charsEncodingBech32Typical Tx Size (1-in, 2-out)VariesFee Saving vs Legacy~32%+Wallet SupportAll modern walletsAddress TypeTaproot (P2TR)Prefixbc1p… 62 charsEncodingBech32mTypical Tx Size (1-in, 2-out)~154 vbytesFee Saving vs Legacy~32%Wallet SupportMost modern wallets
Transaction size data: Spark.money Bitcoin Transaction Size Reference, 2026. Fee savings are approximate and vary with mempool conditions.
Legacy (P2PKH, prefix 1…) is the original format from 2009. The signature stays inside the main transaction body where it counts at full weight. No fee savings. Still universally supported, which is the only reason to use it today, if you’re dealing with very old software that can’t receive anything else.
Nested SegWit (P2SH-P2WPKH, prefix 3…) wraps a SegWit script inside an older P2SH envelope. When SegWit activated in 2017, not all wallets and exchanges immediately added support for the new bc1 format. Nested SegWit was the compatibility bridge: you get partial fee savings, and senders using older software can still pay you. By 2026, this format exists mainly as a fallback. The 3… prefix is shared with non-SegWit P2SH addresses, which means you can’t tell from the address alone whether you’re looking at a SegWit transaction.
Native SegWit (P2WPKH, prefix bc1q…, 42 characters) is the right choice for most users. It uses Bech32 encoding, which is all lowercase, has better error detection than Base58, and eliminates characters that look alike (no capital O, zero, capital I, or lowercase l). A standard 1-input, 2-output P2WPKH transaction costs ~141 vbytes, about 38% less than the equivalent legacy transaction. All active wallets and exchanges support it as of 2026.
Native SegWit multisig (P2WSH, prefix bc1q…, 62 characters) is the script-hash variant, used for multisig wallets and complex spending conditions. The longer address reflects a 32-byte SHA-256 hash rather than the 20-byte hash used by P2WPKH. If you’re running a 2-of-3 multisig setup, P2WSH is the SegWit-native way to do it.
Taproot (P2TR, prefix bc1p…, 62 characters) is SegWit Version 1, activated in 2021. It uses Schnorr signatures rather than ECDSA, which allows multiple signatures to be aggregated into one, making multisig transactions indistinguishable from single-sig on-chain. It offers the lowest fees for single-sig spends and the best privacy. Use it when you’ve confirmed your recipients and their wallets support bc1p addresses.
Quick Recommendation
For most people: use native SegWit (bc1q). It is supported by essentially every active wallet and exchange, saves ~38% in fees compared to legacy, and carries no compatibility risk in 2026.
If your wallet offers Taproot (bc1p) and you’re doing single-signature transactions with recipients whose wallets support it, that gives marginally better fees and improved privacy.
Nested SegWit (3…) is a compatibility fallback. It’s fine, but there’s no reason to default to it anymore.
The Blocksize War: Why SegWit Was So Controversial
SegWit’s technical case was clear. Its path to activation was not.
From 2015 to 2017, Bitcoin was locked in one of the most divisive governance disputes in its history. At its core, the question was simple: how should a decentralized network upgrade its own rules when different factions have conflicting interests?
The Mining Stalemate
Under the standard BIP9 upgrade process, a soft fork required 95% of miners to signal support in a two-week window. By early 2017, SegWit had been ready to activate for months and was stuck below that threshold.
The most significant opposition came from large mining operations, particularly Bitmain, which at the time controlled a substantial share of Bitcoin’s hashrate. The reason that later became clear: Bitmain used a patented technique called ASICBoost, an optimization that gave its mining hardware a meaningful efficiency advantage. SegWit was structurally incompatible with covert ASICBoost. Blocking SegWit protected that advantage.
BIP 148 and the UASF
In March 2017, an anonymous developer using the pseudonym Shaolinfry published BIP 148: a User-Activated Soft Fork (UASF). Rather than waiting for miner signalling, BIP 148 proposed that economic nodes, meaning exchanges, payment processors, and businesses running Bitcoin software, simply begin rejecting any block that didn’t signal SegWit support from August 1, 2017 onwards.
The logic was straightforward: miners produce blocks, but they only have value if the network accepts them. If enough of the economic majority ran BIP 148 nodes, miners would either activate SegWit or watch their blocks get orphaned. The risk was equally clear: if adoption was insufficient, you’d get a chain split, with two incompatible versions of Bitcoin running in parallel.
The UASF campaign was grassroots and loud. Conference badges appeared. Twitter arguments intensified. The phrase “run your own node” took on new urgency.
The New York Agreement and Bitcoin Cash
Faced with the UASF deadline, over 50 major Bitcoin companies convened in New York in May 2017 and signed what became known as the New York Agreement. They agreed to activate SegWit, but also to follow it with a hard fork to double the block size to 2MB.
The compromise satisfied neither camp fully. Developers who opposed large blocks saw SegWit2x as a backdoor hard fork they hadn’t agreed to. Miners and companies who wanted larger blocks still weren’t getting what they originally wanted.
On August 1, 2017, a faction that had wanted a pure block size increase, without SegWit, forked Bitcoin to create Bitcoin Cash (BCH), starting with an 8MB block limit. SegWit activated on Bitcoin on August 24, 2017. The SegWit2x hard fork was abandoned in November 2017 after its organizers concluded they didn’t have sufficient consensus.
What It Settled
The outcome was significant beyond the technical details. The UASF had worked: economic nodes, not miners, determined which consensus rules applied. This is now regularly cited as a demonstration that Bitcoin’s governance ultimately rests with those who run and use the software, not those who produce blocks. August 1 is referred to by parts of the community as Bitcoin Independence Day.
What SegWit Made Possible
The Lightning Network
The Lightning Network was designed before SegWit existed. Its creators knew it could not be safely deployed until transaction malleability was fixed, because payment channels depend on chains of unconfirmed transactions that reference each other by TXID. SegWit’s fixed-TXID guarantee made those channels safe.
The Lightning Network launched on Bitcoin mainnet in early 2018, roughly six months after SegWit activated. By Q1 2025, it had processed over 100 million transactions. Without SegWit, none of that infrastructure would exist.
Taproot and Script Versioning
SegWit introduced script versioning into Bitcoin’s transaction format. The witness program begins with a version byte: SegWit V0 covers P2WPKH and P2WSH. Any future upgrade that defines a new version number gets its own rules without conflicting with existing ones, and without requiring another contentious upgrade battle.
SegWit V1 is Taproot, activated in November 2021. It brought Schnorr signatures, the MAST (Merkelized Abstract Syntax Trees) framework for complex spending conditions, and privacy improvements that make multisig wallets look identical to single-sig transactions on-chain. Every technical capability Taproot introduced relied on the versioning architecture SegWit created.
Ordinals and Inscriptions
The same witness data structure that SegWit introduced, and that Taproot expanded, made it technically feasible to embed arbitrary data, images, text, code, directly into Bitcoin transactions. This is the mechanism behind the Ordinals protocol and Bitcoin inscriptions, which drove a surge in on-chain data usage and pushed Taproot adoption to approximately 42% of transactions in 2024. As inscription activity declined, Taproot usage settled to around 20% of transactions by late 2025, while SegWit V0 remains the dominant format at around 85%.
SegWit in Context: Bitcoin’s Upgrade Timeline
YearEvent2015Pieter Wuille presents SegWit concept at Scaling Bitcoin conference2016BIP 141 formally published; miner signalling stalls below 95% thresholdMarch 2017BIP 148 (UASF) published by ShaolinfryMay 2017New York Agreement signed by 50+ companiesAugust 1, 2017Bitcoin Cash forks from BitcoinAugust 24, 2017SegWit activates on Bitcoin at block 481,824November 2017SegWit2x hard fork abandonedJanuary 2018Lightning Network launches on mainnetNovember 2021Taproot activates, building on SegWit’s versioning system2023-2024Ordinals and inscriptions exploit SegWit/Taproot witness space2026Approximately 85% of Bitcoin transactions use SegWitYear2015EventPieter Wuille presents SegWit concept at Scaling Bitcoin conferenceYear2016EventBIP 141 formally published; miner signalling stalls below 95% thresholdYearMarch 2017EventBIP 148 (UASF) published by ShaolinfryYearMay 2017EventNew York Agreement signed by 50+ companiesYearAugust 1, 2017EventBitcoin Cash forks from BitcoinYearAugust 24, 2017EventSegWit activates on Bitcoin at block 481,824YearNovember 2017EventSegWit2x hard fork abandonedYearJanuary 2018EventLightning Network launches on mainnetYearNovember 2021EventTaproot activates, building on SegWit’s versioning systemYear2023-2024EventOrdinals and inscriptions exploit SegWit/Taproot witness spaceYear2026EventApproximately 85% of Bitcoin transactions use SegWit
Current Adoption
SegWit adoption grew steadily after activation, reaching 30% of transactions within the first few months, then climbing through the 50% mark over the following two years as wallets and exchanges upgraded their software.
As of 2026, approximately 85% of Bitcoin transactions use SegWit. The remaining 15% are legacy transactions from wallets and services that have not upgraded. Taproot (P2TR, SegWit V1) adoption peaked at roughly 42% of transactions in 2024, driven largely by Ordinals inscription activity, before settling to around 20% by late 2025 as inscription volume declined.
The adoption curve mirrors what happened with SegWit itself: new address formats take one to three years to reach mainstream adoption as hardware wallets, exchanges, and payment processors update their software. Taproot support continues to expand across wallet implementations.
SegWit vs. Legacy: Summary of Differences
FeatureLegacy (Pre-SegWit)SegWitSignature locationInside ScriptSig (main tx body)Separate witness fieldBlock size metricSize in bytes (1MB limit)Weight units (4M WU limit)TXID calculationIncludes signature dataExcludes witness dataTransaction malleabilityPossibleFixedTypical 1-in/2-out tx size~226 vbytes~141 vbytes (P2WPKH)Fee savingBaseline~38% lower (P2WPKH vs P2PKH)Lightning Network supportUnsafeRequired; enables payment channelsAddress prefix1…bc1q… (native) or 3… (nested)EncodingBase58Bech32FeatureSignature locationLegacy (Pre-SegWit)Inside ScriptSig (main tx body)SegWitSeparate witness fieldFeatureBlock size metricLegacy (Pre-SegWit)Size in bytes (1MB limit)SegWitWeight units (4M WU limit)FeatureTXID calculationLegacy (Pre-SegWit)Includes signature dataSegWitExcludes witness dataFeatureTransaction malleabilityLegacy (Pre-SegWit)PossibleSegWitFixedFeatureTypical 1-in/2-out tx sizeLegacy (Pre-SegWit)~226 vbytesSegWit~141 vbytes (P2WPKH)FeatureFee savingLegacy (Pre-SegWit)BaselineSegWit~38% lower (P2WPKH vs P2PKH)FeatureLightning Network supportLegacy (Pre-SegWit)UnsafeSegWitRequired; enables payment channelsFeatureAddress prefixLegacy (Pre-SegWit)1…SegWitbc1q… (native) or 3… (nested)FeatureEncodingLegacy (Pre-SegWit)Base58SegWitBech32
Conclusion
SegWit is the protocol upgrade that separated Bitcoin’s signature data from its transaction data, fixed a security flaw that had existed since 2009, reduced transaction fees by roughly a third, and provided the architectural foundation for the Lightning Network, Taproot, and everything built on top of them since.
As of 2026, it is the transaction standard on Bitcoin, processing the vast majority of on-chain activity. The address formats it introduced, particularly native SegWit (bc1q), are what most users should be using by default today. The political battle that surrounded its activation remains one of the most instructive chapters in Bitcoin’s governance history: a demonstration that in a decentralized network, consensus is not something miners grant, it is something users assert.
