Segregated Witness Blockchain
In 2017, the Bitcoin network underwent a major protocol change known as Segregated Witness (SegWit). The idea was first put out by Bitcoin engineers Pieter Wuille in 2015, followed by Eric Lombrozo and Johnson Lau.
SegWit’s main goal was to resolve two significant problems with the Bitcoin network:
- Transaction flexibility.
- Scalability, in particular addressing a blockchain size restriction issue that slowed down Bitcoin transactions.
How SegWit Works: The Segregation of Witness Data
To “segregate” or separate the “witness” data from the majority of the transaction data is the fundamental idea behind SegWit.
- The scripts and unlocking signatures needed to authorize and validate a transaction are referred to as “witness” data.
- The transaction ID (TXID) was generated from the complete transaction data in historical Bitcoin transactions, where the unlocking code, along with signatures, was placed next to each input and dispersed across the transaction data.
- At the conclusion of the transaction data, SegWit transfers all of the signatures and unlocking code to a different data format. The “witness” is the name of this new structure.
Importantly, all of the transaction data aside from the unlocking code is now used to generate the TXID (transaction identifier) in a SegWit transaction. This indicates that the validation code has no bearing on the TXID; rather, it is only affected by the transaction’s outcomes (the flow of bitcoins).
Problems SegWit Addressed
Transaction Malleability Fix
The Issue: Before SegWit, an individual could “mutate” or alter unconfirmed Bitcoin transactions without rendering them void. This was due to the fact that the digital signature, which was used to calculate the TXID, might be slightly altered without rendering the transaction itself void. The same transaction would have a different TXID as a result of this modification. Links between child transactions may be broken, and services like multi-signature wallets and second-layer protocols that depend on fixed TXIDs may experience problems.
SegWit’s Solution: SegWit prevents the TXID from being changed without rendering the entire transaction invalid by isolating the signature data from the transaction data that creates the TXID. TXIDs are hence dependable and unchangeable.
Increased Block Capacity (Scalability)
The Issue: Initially, Bitcoin blocks, which are collections of transactions, could only be one megabyte (MB) in size. The purpose of this limit was to stop denial-of-service (DoS) attacks. But when Bitcoin gained traction, this restriction made it harder to process as many transactions at once, which resulted in network congestion, longer wait times, and more expensive transaction fees.
- Block Weight, SegWit’s solution: SegWit did not raise the 1 MB block size limit in bytes directly. Rather, a new metric known as “block weight” was developed.
- The maximum size of a block is 4,000,000 weight units (WU).
- Four weight units are equivalent to a “normal” byte in a transaction (non-witness data).
- One weight unit is equivalent to a “witness” byte, which is the unlocking code.
- As a result, witness data is essentially given a 75% space reduction, or a 0.25 vs. 1 discount. This implies that a block can contain more transactions, particularly SegWit transactions.
- The 4 million weight unit restriction is equal to the previous 1 million byte limit for a block that exclusively contains non-SegWit transactions.
- The practical limit for ordinary blocks rose to about 1.8 MB, even if the theoretical maximum block size climbed to 4 MB. The “block size increase” is contingent upon the transactions that comprise a block.
Benefits and Impact of SegWit
Enhanced Transaction Throughput
SegWit directly enhanced the network’s processing capacity by efficiently shrinking transaction sizes so that more could fit in a block.
Reduced Transaction Fees
By reducing network congestion, particularly during peak hours, the larger block capacity might result in reduced transaction fees. In order to accommodate more transactions and possibly increase their fee income, miners are encouraged to incorporate SegWit transactions.
Enabling Second-Layer Solutions (Lightning Network)
The creation and secure implementation of the Lightning Network and other off-chain protocols depended on the correction of transaction malleability. Without a stable TXID, these technologies which depend on unconfirmed transactions would be at risk.
Better Address Format (Bech32)
New address formats were introduced by SegWit. Native SegWit addresses begin with “bc1” and employ Bech32 encoding, which is more efficient, more legible (all lowercase), and provides superior error detection.
Enhanced Security
SegWit improves transaction security by segregating the signature data.
Paved the way for future upgrades
Future upgrades were made possible by SegWit, which also cleared the path for later Bitcoin updates like Taproot that improved smart contract capabilities even more.
Implementation and Activation
SegWit was a backwards-compatible update because it was done as a soft fork. This made it possible for “old” nodes those that hadn’t upgraded to continue to recognize SegWit blocks as legitimate and stay up to date with the new nodes on the same blockchain. A “lightweight” version of SegWit transactions would be sent to older nodes, which would see the movement of bitcoins but not the unlocking code.
Activation Procedure
After at least 95% of miners indicated that they were prepared for the upgrade during a target adjustment time of 2016 blocks, SegWit was turned on. By including a specific version number in the blocks they mine, miners indicate when they are ready.
Activation Timeline
SegWit’s activation window opened on November 15, 2016 UTC, and ended on November 15, 2017 UTC. Between blocks 477,792 and 479,807 on August 9, 2017, all miners indicated support for SegWit, “locking in” the upgrade. On August 24, 2017, segregated witness was formally activated at block height 481,824.
Miner vs. Node Control
The consensus rules of Bitcoin are ultimately governed by the economic majority of node operators, not simply the miners, even if a seamless soft fork upgrade required a strong majority of miners to declare their readiness. SegWit’s activation, specifically via the BIP 148 User Activated Soft Fork (UASF), showed that node operators may make modifications and get around blocking miners.
Types of SegWit Addresses
Transactions must employ certain address types in order to take use of SegWit:
- P2SH-SegWit: A “3” usually marks the beginning of these addresses. They may send bitcoin to earlier, non-SegWit wallets even if they don’t fully support SegWit since they are “wrapped” in a Pay-to-Script-Hash (P2SH) format, which offers backward compatibility.
- Native SegWit (Bech32): “bc1” is the first character of these addresses. They are suggested for contemporary wallets that fully support SegWit since they are the most effective and provide the greatest fee reductions. Because they exclusively utilize lowercase letters, they are instantly identifiable.
SegWit also included transaction types that store public keys and signatures in a separate witness field, such as P2WPKH (Pay to Witness Public Key Hash) and P2WSH (Pay to Witness Script Hash). The P2SH-P2WPKH and P2SH-P2WSH wrapped SegWit types provide compatibility with older systems.
SegWit is used in almost all Bitcoin transactions by 2024; as of February 2018, SegWit transactions accounted for over 30% of all Bitcoin transactions. Users can easily send Bitcoin between SegWit and older addresses.
Similar Ideas
Bitcoin Money: Bitcoin Cash was formed by a small group of Bitcoin miners, primarily from China, who were dissatisfied with SegWit’s upgrade plans and proposed alternative ideas.
SegWit2x was a distinct proposal that sought to activate SegWit and raise the block size limit to 2 MB; it should not be confused with BIP141 SegWit. SegWit2x was controversial because of its small developer group and was eventually cancelled on November 8, 2017, due to a lack of consensus, even though it had strong miner support (more than 90% of the hash rate) and support from more than 50 companies (the “New York Agreement”). The majority of developers and node operators rejected SegWit2x because they were worried about possible centralization, greater node operating expenses, and faster blockchain growth rates.