What is Segregated Witness (SegWit)?
The beginner’s guide to Bitcoin SegWit
Segregated Witness (SegWit) was an upgrade made to Bitcoin's source code on August 1, 2017.
Despite making what many saw as improvements to the Bitcoin blockchain, SegWit was met with strong opposition that divided the community.
At the heart of the issue was a competing interest between miners' profitability and network developers seeking to make Bitcoin cheaper and faster to use.
The tension caused a rift within the community, culminating in the network’s first user-activated soft fork and a hostile split. The division birthed a series of new Bitcoin-forked projects, including Bitcoin Cash.
To date, SegWit remains one of the most controversial events in Bitcoin's history. But, it has also proved to be one of its most important updates for the long term viability of the protocol.
Each year, many in the Bitcoin community celebrate August 1 as “Bitcoin independence day.” This event marks the occasion when the will of the people triumphed against the centralized interests of established bitcoin mining companies.
Let’s explore each of these events as they happened and unpack the history behind SegWit.
Bitcoin before SegWit
Before SegWit activation, Bitcoin's block capacity had remained unchanged for many years. Block capacity refers to the maximum number of transactions that can be recorded within a given block.
When Bitcoin launched in 2009, its creator(s) Satoshi Nakamoto did not set any parameters for how big bitcoin blocks could be.
However, in 2010, Nakamoto secretly added a 1-megabyte (MB) block size limit without the approval of other Bitcoin contributors.
This fixed cap on block capacity had the unwanted effect of restricting Bitcoin's potential to scale in several ways.
Low throughput and slow transaction times
Only a limited number of transactions can fit into the comparatively small 1MB block that Bitcoin now adopted. This small capacity meant the Bitcoin network could only process around 2–3 bitcoin (BTC) transactions per second — a far cry from traditional digital payment networks that can process tens of thousands of transactions per second.
Additionally, for a block of transactions to be considered valid as part of the bitcoin mining process, it must receive six confirmations. In other words, six new blocks must be added to the blockchain after the block in question before it is finalized. With an average block time of ten minutes, this means bitcoin block confirmations take around one hour.
At the time, when only a handful of “Cypherpunk” cryptographers were aware of bitcoin, it was not necessarily a huge issue. But, if the Bitcoin network was to become a global “peer-to-peer electronic cash system” as Satoshi envisioned in the Bitcoin white paper, things needed to change.
Bitcoin's low throughput, constrained by its small block capacity, meant fees were also comparatively much higher than they are today.
Here’s an easy way to understand this issue. Imagine you are standing outside in a crowd of people after watching a theater show. Everybody from the theater wants to take a taxi home all at the same time. If there are plenty of taxis around, it should be easy for everyone to get home. But, if there are only a handful of cabs, people might try to pay a higher price to the taxi drivers in order to incentivize the driver to take them home first. Depending on demand, prices for taxis could shoot up significantly higher than the normal rate.
Bitcoin fees work off these same principles of supply and demand. If a lot of people want their transactions processed at the same time, some may opt to pay more in fees to get their transaction processed sooner by miners. During periods of high usage on the Bitcoin network, congestion can result in competition among users, which can cause transaction fees to spike sharply.
Another inherent nuance with the way Bitcoin blocks worked was known as transaction malleability. Before SegWit, people could change the ID of a transaction before it received enough confirmations on the blockchain.
Taking the information related to a specific transaction and running it through a hash function creates a transaction ID. You can learn more about hash functions in our article How do cryptocurrencies use cryptography?
But for simplicity, you can think of these transaction IDs as digital fingerprints which are used to identify and reference transactions on the blockchain.
Changing the transaction ID creates an entirely new hash which could sometimes confuse blockchain client software. All nodes run client software to interact with the blockchain and perform important roles such as data verification.
This malleability bug in Bitcoin's code opened the door to malicious attacks. One of the most infamous examples of a transaction malleability attack was the Mt. Gox exchange hack of 2014 — renowned for being the largest bitcoin hack in history.
Experts reported a hacker, or group of hackers, drained Mt. Gox exchange's bitcoin wallet. They did this in part by altering the transaction ID of their withdrawals.
The transaction malleability attack made it appear as though withdrawals weren't being confirmed on the blockchain, when in actual fact they were.
This vulnerability, coupled with other attack vectors, enabled the hacker(s) to siphon over 840,000 BTC from the exchange.
What improvements did SegWit make?
Bitcoin contributor Pieter Wuille first presented the SegWit upgrade at a Bitcoin Hong Kong event in 2015.
His solution was innovative on three fronts. SegWit improved Bitcoin's scalability, removed malleability, and allowed nodes to adopt the new transaction structure. Best of all, this could be implemented without hard-forking the network.
Separate digital signature and transaction information
Wuille's proposal increased Bitcoin block capacity by "segregating" the "witness" data from a block and moving it to the coinbase transaction. Coinbase transactions are the very first transactions within each new Bitcoin block. The coinbase transaction is responsible for issuing newly minted cryptocurrency into circulation as a reward for the bitcoin mining process.
Miners that succeed in winning Bitcoin's cryptography-based proof-of-work competition earn these newly minted tokens as "block rewards."
Witness data, also known as ScriptSig or Unlocking Script, includes digital signature and public key information needed to unlock the transferred bitcoin. The SegWit upgrade introduced a separate "witness field" for the ScriptSig part of a transaction.
By processing digital signature information separately from the transaction input field, there was more space of transactions to fit in each block.
More transactions per block equals higher transaction throughput capabilities. So, instead of 2-3 transactions per second, Bitcoin can process between 7-10 SegWit transactions per second. Increased capacity also means lower fees, as the Bitcoin blockchain can handle a higher volume of transactions.
Despite the separation, it's important to note that nodes still process both the transaction data and the witness data on-chain. No sidechain or Layer 2 protocol are used.
Before SegWit, miners measured bitcoin blocks by size (in bytes). This system worked well when blocks contained both witness and transaction data, but ran into issues when they were separated.
To overcome this, the upgrade introduced a metric called block weight to manage the size of blocks.
With this concept, each 1-megabyte block consists of 4,000,000 weight units (WU). Each transaction is given a weight based on the following formula:
Base transaction size in bytes (with no witness data) * 3 + Total transaction size in bytes.
By removing witness field data from the calculation, SegWit transactions have a much lower weight. On the other hand, a non-SegWit transaction still contains witness data. This means that non-SegWit transactions always weigh 4 times more than SegWit transactions.
This concept theoretically increases the size of a bitcoin block from 1MB to 4MB, if a block consists almost entirely of witness data. However, this is not possible in practice.
The main benefit of the weighted system is that it incentivizes miners to process blocks containing mostly SegWit transactions. Assuming SegWit transactions carry the same fees as legacy blocks, a miner can process a lot more SegWit transactions per block. The more transactions they process per block, the more fees they earn.
A win-win for both parties. Or so you would think.
No more transaction malleability issues
Under the SegWit structure, the hashed transaction ID only contains the transaction information, not the witness field information.
This change removes the modifiable component of a bitcoin transaction that previously enabled malleability attacks.
As a result, secondary scaling solutions such as the Bitcoin Lightning Network became possible.
Why was SegWit controversial?
Many in the development community felt that SegWit didn't go far enough to address Bitcoin's scaling issues.
The main arguments against SegWit's activation include:
- Bitcoin's increased throughput of 7-10 transactions per second is still nowhere near high enough for a decentralized, global payment system.
- Fees would remain relatively high, making things like microtransactions financially unfeasible.
- Miners can still process legacy transaction blocks, meaning malleability is still a threat.
- It was later discovered that SegWit would negate Bitmain’s ASICBOOST mechanism; an exploit used to significantly increase mining rig efficiency.
Around one year after Wuille’s proposal, he and other Bitcoin Core developers including Eric Lombrozo had prepared the code to go live in the upcoming Bitcoin Core 0.13.1 update. The only remaining step to activate SegWit was for miners to start processing new SegWit blocks.
To cement its implementation, over 95% of all bitcoin miners would need to show support for SegWit within the first two weeks of its initiation — a major hurdle considering the circumstances at that time.
User-activated soft fork
Needless to say, large mining firms such as Bitmain were still unhappy with the proposed changes and refused to support SegWit’s activation.
In early 2017, a pseudonymous developer named “Shaolinfry” raised the possibility of Bitcoin nodes enforcing a soft fork in an online bitcoin-dev post.
A user-activated soft fork had never been attempted on the Bitcoin network before, but it would allow developers to push through SegWit with around 51% support from miners. Those that refused to support new blocks risked having their blocks rejected by nodes. The solution wasn’t without its risks. If SegWit failed to receive sufficient backing from miners, the outcome would invariably lead to a chain split.
Those against SegWit proposed a different SegWit 2X hard fork upgrade instead. One that would implement SegWit and increase Bitcoin's block size to 2MB.
Unlike the former upgrade, SegWit 2X would not be backward compatible with previous versions of the Bitcoin client. These changes meant nodes would have to update their software to continue operating on the network.
SegWit & the New York agreement
The industry's top companies met at Consensus 2017 and collectively signed a memorandum dubbed "the New York Agreement." This document laid out plans for SegWit to go live in the Summer and for Bitcoin's block size to increase to 2MB by November.
Ahead of November, Shaolinfry drafted two Bitcoin Improvement Proposals (BIPs); BIP148 and BIP149. The former represented a hard and fast solution; signal support for SegWit blocks or nodes will reject your blocks. The latter provided a longer time horizon for miners to onboard, setting an activation deadline for July the following year.
As the date drew near, Bitmain Warranty engineer, James Hillard, proposed a new BIP; BIP91. His solution sought to make both SegWit 2X and BIP148 compatible with one another. Why risk a chain split over two competing SegWit updates when you can make them both compatible?
On August 1, sufficient mining support cemented SegWit’s activation. The second stage of the New York Agreement, however, failed to receive the same backing.
The failure to increase Bitcoin’s block size to 2MB resulted in the formation of Bitcoin Cash (BCH) — a new forked project from the Bitcoin blockchain.
The importance of Bitcoin independence day
The introduction of SegWit and the community’s decision to reject the block size increase represented a landmark moment for the broader Bitcoin community.
SegWit showed the importance of consensus when it came to changes to the Bitcoin blockchain as well as the extent of the decentralization of power that bitcoin offered.
No single individual was able to take over the network and see their proposal through.
Instead, the community debated, iterated and continued the long process of reaching consensus as a collective group — not at the direction of a single individual.