Segregated Witness, commonly referred to as SegWit, was introduced as an upgrade to the Bitcoin Core in 2017. This protocol upgrade brought about several pivotal improvements to the Bitcoin network, addressing challenges such as transaction malleability and scalability. Furthermore, it laid the groundwork for future enhancements, including the Taproot upgrade. The primary objective of SegWit was to segregate transaction data from signature data, thereby allowing more transactions to be included in a block. The activation of SegWit, however, was a matter of contention, leading to significant divisions within the Bitcoin community. Despite these challenges, Bitcoin showcased its decentralized nature and resilience against potential takeovers by miners and community leaders.
Transaction malleability refers to the potential for a transaction to have multiple valid transaction IDs (txids). This malleability arises when a part of a transaction can be altered after its signing without invalidating the signature. Such an issue posed significant challenges, especially for developers and users who wanted to reference a previous transaction in a new one before the former was confirmed on the blockchain. Transaction malleability was a significant barrier to the adoption of the Lightning Network, which relies on exchanging unconfirmed Bitcoin transactions.
How SegWit Addresses Transaction Malleability
SegWit tackled this issue by removing all data from the ScriptSig, moving the ScriptSig data (typically signatures and public keys) to the Witness, a new segment of SegWit transactions that isn’t used to calculate the txid. This change ensured that the ScriptSig couldn’t be altered, preventing the txid from being changed without invalidating the entire transaction.
SegWit and the Lightning Network
The activation of SegWit facilitated the launch of the Lightning Network as a second layer atop the Bitcoin network. Before SegWit’s activation, the Lightning Network was not feasible due to its reliance on unconfirmed bitcoin transactions, making it vulnerable to attacks as long as transaction malleability persisted.
Block Size Increase with SegWit
While SegWit is a soft fork, it modified one of Bitcoin’s consensus rules in a backward-compatible manner to allow more transactions per block. Before SegWit, each block had a 1MB data limit, translating to about 1650 transactions in a full block. With SegWit, this changed to block weight, replacing block size as the limiting factor. As a result, full blocks now contain around 2700 transactions.
SegWit’s New Script Types
SegWit introduced two new script types to utilize the Witness field: Pay-to-Witness-Pubkey-Hash (P2WPKH) and Pay-to-Witness-Script-Hash (P2WSH). These new script types were essential for making the most of the Witness field.
Bech32: SegWit’s New Encoding Scheme
SegWit also introduced a new encoding scheme for its addresses, known as Bech32. This scheme was an improvement over the previous Base58 as it never mixed letter casing, making it more legible and better suited for QR encoding. Bech32 also has an in-built error detection mechanism, aiding users and wallets in identifying and even rectifying typos or changes in an address.
SegWit’s History and Activation
The SegWit upgrade was highly controversial, impacting both the development process and the community. Initially proposed for Bitcoin Core in 2015, SegWit aimed to solve transaction malleability and make more space on the blockchain. However, concerns about Bitcoin’s scalability led to proposals like SegWit2x, which sought to double the block weight limit. This proposal, despite gaining significant support, was eventually rejected in favor of BIP 148, which successfully implemented SegWit.
Lessons from SegWit
The debates surrounding SegWit and SegWit2x highlighted that nodes, not miners or businesses, control the network. Nodes running their software could override the majority of miners, implementing SegWit and rejecting SegWit2x. This resilience reaffirmed the belief in Bitcoin’s decentralized nature.