Case Study 2: SegWit Adoption — A Study in Protocol Upgrades

Background: The Scaling Debate

By 2015, Bitcoin was approaching a crisis. The 1 MB block size limit, which Satoshi Nakamoto had added in 2010 as an anti-spam measure, was becoming a binding constraint. Blocks were regularly reaching capacity. Transaction fees were rising. Confirmation times were becoming unpredictable. The Bitcoin community needed to increase the network's transaction throughput, and the disagreement over how to do it became one of the most contentious debates in the history of open-source software.

Two camps emerged:

The "Big Block" camp advocated for a straightforward increase in the block size limit — from 1 MB to 2 MB, 8 MB, or even larger. Their argument was simple: the limit was arbitrary, technology had advanced, and a direct increase was the most straightforward path to more transactions per block. Prominent supporters included Roger Ver, Gavin Andresen, and the mining company Bitmain.

The "SegWit" camp advocated for Segregated Witness, a more complex change that would increase effective block capacity by restructuring the transaction format while also fixing the transaction malleability bug. Their argument was that a direct block size increase via hard fork was risky (potentially splitting the network), while SegWit could be deployed as a backward-compatible soft fork and also enabled the Lightning Network for off-chain scaling. Prominent supporters included the Bitcoin Core development team, Blockstream, and many long-term contributors.

The debate was not merely technical. It involved fundamental disagreements about Bitcoin's governance, its purpose (medium of exchange vs. store of value), and who had the authority to make changes to the protocol.

The Technical Proposal

BIP 141: Segregated Witness

SegWit was formally specified in BIP (Bitcoin Improvement Proposal) 141, authored by Eric Lombroze, Johnson Lau, and Pieter Wuille. Pieter Wuille presented the proposal at the Scaling Bitcoin conference in Hong Kong in December 2015.

The key technical innovations were:

1. Witness segregation. Signature data (the "witness") was moved to a new section of the transaction, outside the data used to compute the transaction ID. This fixed transaction malleability — the ability for third parties to change a transaction's hash without invalidating it.

2. Block weight. Instead of a raw 1 MB byte limit, SegWit introduced a weight-based limit: 4,000,000 weight units (WU). Non-witness data counted at 4 WU per byte, while witness data counted at 1 WU per byte. This effectively increased the maximum block size to approximately 4 MB (if the block were entirely witness data) or about 1.8-2.1 MB for typical transaction mixes.

3. Script versioning. SegWit introduced a versioning mechanism for locking scripts, making it easier to deploy future upgrades. This was the foundation that later enabled the Taproot upgrade in 2021.

4. Soft fork deployment. The entire change was backward-compatible. Old nodes could still process SegWit transactions — they saw the SegWit outputs as "anyone can spend" outputs. But as long as a majority of miners enforced the new SegWit rules, the network was secure.

Why Soft Fork Matters

The distinction between a hard fork and a soft fork is fundamental to understanding this debate.

A hard fork relaxes the consensus rules — blocks that were invalid under the old rules become valid under the new rules. Every node must upgrade, or the network splits permanently. If even a minority of nodes refuse to upgrade, they will follow a different chain, creating two separate cryptocurrencies.

A soft fork tightens the consensus rules — blocks that were valid under the old rules might be invalid under the new rules, but blocks valid under the new rules are always valid under the old rules. Old nodes can continue operating without upgrading. They will accept the new blocks (which are still valid by their rules) and follow the majority chain.

SegWit's advocates argued that a soft fork was safer because it did not force every node to upgrade simultaneously and did not risk permanently splitting the network.

The Political Conflict

Miner Resistance

SegWit was proposed in December 2015, but its activation was delayed for nearly two years by miner resistance. Under the original activation mechanism (BIP 9), miners signaled their support by setting a specific bit in the block version field. SegWit required 95% of blocks in a 2,016-block difficulty period to signal support before it could activate.

By early 2017, SegWit signaling was stuck at approximately 30%. Many miners, particularly those affiliated with Bitmain and its associated mining pools, refused to signal support. The reasons were complex:

1. AsicBoost. Bitmain held a patent on a mining optimization called AsicBoost, which exploited a quirk in how the Bitcoin block header was hashed. SegWit's changes to the block structure would have made "covert AsicBoost" — the version of the optimization that was not publicly visible — impossible. This gave Bitmain a financial incentive to oppose SegWit, though they denied this was the primary reason.

2. Hard fork preference. Many miners and large-block advocates preferred a hard fork to increase the block size directly. They viewed SegWit as an unnecessarily complex solution that also happened to benefit Blockstream's Lightning Network business model.

3. Governance philosophy. The conflict reflected a deeper disagreement about who controlled Bitcoin. Miners argued that their hash power gave them a decisive voice in protocol changes. Developers argued that they wrote the code and understood the technical tradeoffs. Users argued that neither miners nor developers should have unilateral authority.

The Hong Kong Agreement and the New York Agreement

In February 2016, a group of Bitcoin Core developers and mining company representatives met in Hong Kong and reached an informal agreement: Core developers would work on a hard fork block size increase in addition to SegWit. This agreement was controversial and ultimately fell apart, with each side accusing the other of reneging.

In May 2017, a group of major Bitcoin companies and mining pools (representing a significant fraction of the network's hash power) met in New York and signed the "New York Agreement" (also called "SegWit2x"). The proposal was: 1. Activate SegWit via BIP 91 (a lower threshold than BIP 9) 2. Follow with a hard fork to double the block weight limit within 6 months

The New York Agreement was signed by over 50 companies, but it was not endorsed by the Bitcoin Core development team and was opposed by many community members who viewed it as an attempt by a small group of companies to seize control of Bitcoin's governance.

UASF: User Activated Soft Fork

Frustrated by miner resistance, a grassroots movement emerged in early 2017: the User Activated Soft Fork (UASF), specified in BIP 148. The UASF proposal was radical: starting August 1, 2017, nodes running the BIP 148 software would reject any block that did not signal support for SegWit, regardless of whether the 95% miner threshold had been met.

The UASF was a statement of principle: users, not miners, ultimately determine which rules the network follows. If enough economic actors (exchanges, merchants, wallet providers) ran UASF nodes, miners who did not signal SegWit would risk mining blocks that the economic majority rejected — effectively mining worthless blocks.

The UASF movement gained significant traction. Users ran UASF nodes, exchanged "UASF" hats, and lobbied exchanges and businesses to support BIP 148. The movement demonstrated something important: in a decentralized network, miners have hash power, but users have economic power. A block that no exchange accepts and no merchant honors is worthless, regardless of how much proof of work it contains.

The Resolution

BIP 91 and Lock-In

Facing the August 1 UASF deadline, miners began signaling for SegWit at an increasing rate. BIP 91 (proposed by James Hilliard) provided a compromise: it required only 80% miner signaling (instead of 95%) and was compatible with both BIP 148 and BIP 141.

On July 20, 2017, BIP 91 locked in with overwhelming miner support. On July 23, it activated. On August 8, SegWit itself reached the 95% BIP 9 signaling threshold. On August 24, 2017, SegWit activated on the Bitcoin mainnet at block height 481,824.

The Bitcoin Cash Fork

Not everyone accepted SegWit. On August 1, 2017 — the same date the UASF was set to activate — a group led by major-block advocates and supported by Bitmain launched Bitcoin Cash (BCH), a hard fork of Bitcoin that increased the block size to 8 MB (later 32 MB) and did not include SegWit.

Bitcoin Cash represented the "big block" philosophy taken to its logical conclusion: scale the base layer directly by increasing block size. Bitcoin (with SegWit) represented the "layered scaling" philosophy: keep the base layer compact and build scaling solutions (like the Lightning Network) on top.

Both chains survived. Bitcoin retained the majority of hash power, market capitalization, and ecosystem support. Bitcoin Cash attracted a smaller but dedicated community. As of 2025, Bitcoin's market capitalization is roughly 100 times that of Bitcoin Cash, though BCH continues to operate as an independent blockchain.

SegWit2x Collapse

The second part of the New York Agreement — the hard fork to double the block weight — was scheduled for November 2017. However, as the date approached, support evaporated. Several major signatories withdrew. Without broad consensus, the SegWit2x hard fork was called off on November 8, 2017, just days before the planned activation.

The collapse of SegWit2x was a defining moment in Bitcoin governance. It demonstrated that no closed-door agreement among companies could override the broader community's consensus. The "rough consensus" model — where changes require near-universal buy-in from developers, miners, users, and economic actors — had held.

Adoption Trajectory

Slow Start

Despite being activated in August 2017, SegWit adoption was remarkably slow in its first year:

The slow adoption curve reveals an important lesson: deploying a protocol upgrade is only half the battle. Adoption requires wallet developers, exchanges, and service providers to update their software. Many of these entities are risk-averse and move slowly, especially when the change requires modifying transaction-creation logic.

The Fee Savings

SegWit delivered measurable economic benefits. For a typical transaction (1 input, 2 outputs):

The savings are even more dramatic for complex transactions. A 2-of-3 multisig transaction saves approximately 50% in fees when using native SegWit versus legacy format.

Enabling the Lightning Network

Perhaps SegWit's most important long-term impact was enabling the Lightning Network. The Lightning Network requires creating chains of unconfirmed transactions — transactions that spend outputs of other unconfirmed transactions. This is only safe if transaction IDs are not malleable.

Before SegWit, a malicious party could change a transaction's ID after broadcast, breaking any dependent transactions. With SegWit, the transaction ID is computed without the witness data, making it immutable once the transaction is created (even before confirmation). This guarantee is the foundation on which the Lightning Network is built.

As of 2025, the Lightning Network processes millions of transactions daily, with a public network capacity exceeding 5,000 BTC. None of this would be possible without SegWit's malleability fix.

Lessons for Protocol Governance

1. Decentralized Governance Is Messy but Effective

The SegWit saga took over two years from proposal to activation. It involved intense technical debates, political maneuvering, corporate agreements, grassroots activism, and a permanent chain split (Bitcoin Cash). By any conventional measure, this is a dysfunctional governance process.

And yet, the outcome was arguably the best possible: - The upgrade that had the broadest technical and community support was activated. - A minority with a different vision launched their own chain (Bitcoin Cash) without being forced to comply with the majority. - No single entity — not the developers, not the miners, not the companies — was able to dictate the outcome. - The process, though painful, validated Bitcoin's decentralized governance model.

2. Soft Forks Enable Gradual Adoption

SegWit's deployment as a soft fork meant that nodes could upgrade at their own pace. Eight years after activation, some nodes still have not upgraded — and they continue to function. They accept SegWit blocks (which are valid under the old rules), they relay transactions, and they participate in the network. They simply cannot take advantage of SegWit's features.

This backward compatibility is a powerful property. It means that protocol upgrades do not require unanimous coordination, they do not have hard deadlines, and they do not risk splitting the network.

3. Users Are the Ultimate Authority

The UASF movement established a principle that continues to shape Bitcoin governance: users, not miners, are the ultimate authority. Miners provide security, but they do not define the rules. The rules are defined by the nodes that economic actors run — the exchanges, the merchants, the wallet providers. If the economic majority runs software that enforces a particular rule, miners must comply or mine worthless blocks.

This principle was reinforced by the collapse of SegWit2x. Despite having majority miner support and the backing of over 50 companies, SegWit2x failed because it did not have the support of the broader user community. The "New York Agreement" could not override "rough consensus."

4. Protocol Upgrades Have Real Costs

The block size debate and SegWit activation consumed an enormous amount of community energy. Relationships were damaged. Community members were harassed. Companies took sides and lost customers. The Bitcoin Cash fork fragmented the ecosystem and diluted developer attention.

These costs are not captured in any technical specification. They are the social cost of changing a decentralized protocol, and they explain why Bitcoin's development culture is deeply conservative. Every proposed change is scrutinized not only for its technical merits but for its potential to cause social disruption. The bar for activation is deliberately high.

Connection to Chapter Concepts

The SegWit case study connects directly to this chapter's technical content:

Transaction structure. SegWit fundamentally changed how transactions are serialized — adding the marker/flag bytes, moving signature data to the witness section, and creating new address formats. Understanding the pre-SegWit and post-SegWit transaction formats is essential.

Weight and virtual bytes. The weight formula (non-witness bytes * 4 + witness bytes * 1) and the 4 MWU block limit are concepts introduced by SegWit that every Bitcoin developer must understand.

Transaction malleability. The malleability problem — which SegWit solved — arises from the fact that the signature data was included in the txid computation. Understanding why this was a problem requires understanding how transactions reference each other via txids (the input's previous transaction hash field).

Script evolution. SegWit introduced script versioning (witness version 0 for P2WPKH and P2WSH, witness version 1 for Taproot), laying the groundwork for future scripting improvements without contentious soft forks.

Discussion Questions

1. The UASF demonstrated that users, not miners, are the ultimate authority in Bitcoin governance. But what if the economic majority of users wanted a change that was technically unsound? Should developer expertise override user preference? Where is the balance?

2. Bitcoin Cash launched as a direct result of the SegWit debate. Was the fork a success or a failure of Bitcoin's governance model? What does the subsequent price history of BCH relative to BTC suggest about the market's verdict?

3. SegWit adoption took over 7 years to reach approximately 87%. What factors slowed adoption, and what could be done differently to accelerate adoption of future upgrades?

4. The Taproot upgrade (2021) activated with much less controversy than SegWit. What lessons from the SegWit activation process were applied? What technical and social factors made Taproot easier to activate?

5. Compare the SegWit governance process to how Ethereum handled its major upgrades (e.g., the Merge to proof of stake). What are the structural differences between Bitcoin's and Ethereum's governance models, and how do those differences affect their ability to evolve?

Further Reading

• BIP 141: Segregated Witness (Consensus Layer) — the full specification
• BIP 143: Transaction Signature Verification for Version 0 Witness Program
• BIP 148: Mandatory activation of segwit deployment (the UASF proposal)
• "The Long Road to SegWit" by Aaron van Wirdum (Bitcoin Magazine, multi-part series)
• "The Blocksize War" by Jonathan Bier — a comprehensive book-length account of the debate
• Bitcoin Optech: SegWit Adoption Tracking Dashboard
• Lightning Network paper: "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments" by Poon and Dryja (2016)