SegWit (Segregated Witness)

Transaction Malleability

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.