By 2015, Bitcoin was hitting a wall. Fees were climbing, confirmations were taking hours, and the community was tearing itself apart over how to fix it. Segregated Witness—SegWit to everyone who works in the space—was the technical solution that mostly resolved these problems without splitting the network. It didn’t just improve Bitcoin’s performance metrics; it fundamentally changed how transactions are stored, validated, and transmitted. The result was roughly double the on-chain capacity and the unlock of second-layer innovations that weren’t possible before.
This article breaks down exactly what SegWit changed, why it worked, and what the numbers actually look like in practice.
What Segregated Witness Actually Is
SegWit is a protocol upgrade activated on Bitcoin in August 2017 via a soft fork—a backward-compatible change that doesn’t split the network into two separate currencies. The name describes exactly what happens: witness data, which contains the cryptographic signatures proving that Bitcoin owners are authorized to spend their coins, is separated from the transaction data and moved to the end of each block.
Before SegWit, every Bitcoin transaction stored its signature data inline alongside the sender, recipient, and amount information. This was inefficient for two reasons. First, signature data is bulky—signatures typically account for 60-70% of the raw bytes in a transaction. Second, the way signatures were embedded created a phenomenon called transaction malleability, where anyone could slightly modify a transaction’s unique identifier (its hash) without invalidating the signature. This might sound like a minor technical nuisance, but it made it dangerous to build certain types of applications on top of Bitcoin, including many second-layer protocols.
SegWit addressed both problems at once. Moving signatures outside the main transaction data created more efficient block space utilization and eliminated the specific type of malleability that had plagued Bitcoin for years.
The Capacity Numbers: What Actually Changed
Here’s where things get tricky, because the capacity increase is often described in ways that are technically accurate but potentially misleading.
A legacy Bitcoin block has a maximum size of 1 megabyte. Under ideal conditions—with many small transactions—this translated to roughly 3-7 transactions per second (TPS) depending on transaction size and composition.
A SegWit block can theoretically reach 4 megabytes, but this maximum rarely occurs in practice. More realistic average block sizes since activation have been in the 2-2.5 MB range. This still represents a 100-150% increase over the pre-SegWit average of approximately 1-1.2 MB per block.
The practical throughput translates to roughly 7-15 TPS under normal conditions, with some estimates reaching up to 20 TPS during optimal usage patterns. That’s a meaningful improvement, but it’s not the 4x or 8x increase that some early descriptions suggested.
The reason for the discrepancy lies in how SegWit calculates block space. It introduced a concept called “block weight,” where witness data is counted at only 1/4 the rate of regular transaction data. A block can contain more total bytes, but the weight calculation gives preference to the more valuable non-signature data. This clever accounting is what allows the capacity increase without requiring a hard fork—the old 1 MB limit is technically still there in spirit, just measured differently.
How the Technical Mechanism Works
Understanding why SegWit increases capacity requires understanding what happens when you create a Bitcoin transaction.
In a legacy transaction, the data includes the input (where the bitcoin is coming from), the output (where it’s going), and the signature that authorizes the transfer. All of this gets serialized into a fixed-size block.
With SegWit, the transaction is structured differently. The base transaction—the inputs and outputs—remains unchanged. But the signature data gets placed in a separate structure called the “witness,” which lives outside the main transaction ID calculation. The block can fit more transactions because the heavy signature data is counted differently.
There’s another important detail: SegWit introduced a concept called “weight units” (WU). The maximum block weight is 4 million WU, and legacy transaction data counts at 4 WU per byte while witness data counts at 1 WU per byte. This is the mathematical mechanism that enables the 2-4x capacity improvement. A block filled entirely with non-witness data would be limited to 1 MB; a block filled entirely with witness data could reach 4 MB; the actual mix determines where any given block falls in that range.
This is also why the capacity increase is sometimes called a “soft fork increase”—the old rules are still enforced for non-SegWit transactions, but SegWit transactions get access to the expanded capacity through the weight calculation.
Transaction Malleability: The Problem Nobody Talked About
Before SegWit, if you broadcast a Bitcoin transaction, someone could take that transaction’s ID (its unique identifier in the network) and modify the signature in a way that produced a different valid ID but still valid transaction. This is transaction malleability, and it was a serious obstacle to building robust financial infrastructure on Bitcoin.
Why does malleability matter? Consider a scenario where you send bitcoin to an exchange, the exchange sees the transaction but waits for confirmation, and meanwhile someone malleates the transaction ID. If you later complain that your transaction wasn’t confirmed, the exchange can point to a different transaction ID than the one you originally broadcast. The blockchain has both—the original and the malleated version—but your proof doesn’t match theirs.
This might seem like an edge case, but it was catastrophic for certain applications. Any system that tracks transactions by their ID—including payment channels, atomic swaps, and most Lightning Network implementations—could be broken or confused by malleability. Developers had to build workarounds that added complexity and risk.
SegWit eliminated this by moving signatures outside the transaction ID calculation. The transaction ID is now calculated only from the inputs and outputs—the parts that don’t change when the signature is present. Even if someone tries to malleate the witness data, the transaction ID remains stable. This seemingly obscure fix was actually one of the primary motivations for SegWit among developers, even though users mostly noticed the capacity increase.
The Lightning Network Enablement
If the capacity increase was the headline benefit, Lightning Network compatibility was the long-term bet that justified SegWit’s complexity.
Lightning Network is a second-layer protocol that enables nearly instant, extremely low-fee Bitcoin transactions by moving most transactions off-chain. Two participants open a payment channel by creating an on-chain transaction, then they can transact unlimited times between themselves off-chain, settling only the final balance to the main blockchain when they close the channel.
The technical requirements for Lightning are demanding. Payment channels require constructing transactions that depend on previous transactions in complex ways. Without SegWit’s malleability fix, any of those dependent transactions could have their IDs changed by network participants, potentially causing the entire channel to fail or funds to be lost. The original Lightning whitepaper, published by Joseph Poon and Thaddeus Dryja in 2016, explicitly noted that SegWit was necessary for Lightning to be safe to deploy.
Since SegWit’s activation, Lightning Network has grown from a theoretical protocol to a functioning network with thousands of nodes and millions of dollars in capacity. While adoption remains niche compared to on-chain transactions, the infrastructure now exists precisely because SegWit solved the underlying technical barriers. This is a benefit that can’t be captured in a simple “transactions per second” metric—it’s an entirely new capability that was impossible before August 2017.
Real-World Adoption and Usage
As of early 2025, SegWit adoption has become the dominant standard for Bitcoin transactions. Major exchanges, wallet providers, and payment processors have largely migrated to SegWit-compatible addresses.
The exact adoption percentage varies by measurement methodology, but industry estimates suggest that 70-80% of on-chain Bitcoin transactions now use SegWit. This wasn’t immediate—it took several years for wallet developers to implement the necessary changes and for users to migrate from legacy addresses. The transition accelerated significantly after 2020 as fee economics made the efficiency gains economically meaningful.
The fee savings are tangible. SegWit transactions are cheaper to broadcast and confirm because they use less block space per unit of value transferred. During periods of high network congestion, the difference can be 30-50% in fees compared to legacy transactions of equivalent value. For frequent Bitcoin users—particularly those transacting smaller amounts regularly—the efficiency advantage has substantial financial impact.
That said, there’s a nuance worth acknowledging: the capacity increase benefits all users indirectly through reduced congestion, but the direct fee savings only apply to users who actively use SegWit-compatible wallets and addresses. Legacy transactions still work, they still confirm, but they pay a premium during busy periods. Many users don’t realize their wallet is still using legacy addresses, and the transition has been slower than many in the technical community expected.
Addressing Common Misconceptions
One persistent misconception is that SegWit somehow “changed” Bitcoin’s fundamental properties or went against the original design. This is incorrect. SegWit was designed by Bitcoin developers including Pieter Wuille, Gregory Maxwell, and others who were deeply invested in maintaining Bitcoin’s core properties. It was a soft fork, meaning old nodes still validate transactions correctly—they just don’t see the efficiency gains. The Bitcoin you could send before SegWit is exactly the same Bitcoin you send after.
Another misconception: some people believe SegWit increased capacity by “only” 2x when they were promised 2x, and therefore consider it a failure. This misses the point that even a 2x increase in practical throughput was transformative for user experience during congestion periods. The theoretical 4x maximum exists but was never the realistic target—developers always described the increase as approximately 2x for typical usage patterns.
Finally, there’s the confusion between SegWit and “native SegWit” (also called bech32). SegWit is the protocol upgrade; native SegWit is a specific address format (starting with “bc1”) that uses the most efficient possible encoding. Using a SegWit-enabled exchange that still gives you a legacy-style address (starting with “1” or “3”) is like buying a fuel-efficient car but filling it with regular gasoline. The capacity benefits only apply when the entire chain—from sender to receiver—supports SegWit.
Looking Forward: What Remains Unresolved
SegWit solved immediate capacity problems and enabled second-layer innovation, but it wasn’t meant to be the final answer. The Bitcoin scaling debate continues in quieter form, with discussions about further block size increases, covenant proposals, and other protocol enhancements still debated among developers and researchers.
What remains genuinely unresolved is whether Bitcoin’s on-chain capacity can or should continue to expand, or whether the long-term vision should lean more heavily on second-layer solutions like Lightning. Both approaches have passionate advocates, and the technical tradeoffs involve security assumptions, decentralization, and practical usability in ways that aren’t fully settled.
What is clear: SegWit demonstrated that Bitcoin can evolve through soft forks when there’s sufficient consensus, that meaningful capacity improvements are possible without sacrificing security, and that the “scaling debate” produces actual solutions when the political and technical conditions align. Whether those conditions will align again for further changes remains the open question that will shape Bitcoin’s next decade.
