What Is Segregated Witness (SegWit)? | River Learn - Bitcoin Technology (2024)

Introduction

Segregated Witness, often abbreviated to SegWit, was an upgrade implemented in Bitcoin Core in 2017. SegWit improved several aspects of Bitcoin and opened the door to future upgrades, including Taproot.

Firstly and most critically, SegWit fixed transaction malleability. It also raised Bitcoin’s block size limit, allowing more transactions to be included in each block. Lastly, SegWit introduced two new script types—ways of sending and receiving bitcoin—and a new encoding scheme called Bech32.

The SegWit upgrade was contentious, and its activation caused deep divides within the Bitcoin community. However, Bitcoin emerged stronger and more scalable, proving its decentralization could withstand an attempted takeover by miners and community leaders.

What Is Transaction Malleability?

Transaction malleability is the ability of a transaction to have multiple valid txids. Malleability occurs when a part of a transaction can change after the transaction has been signed without invalidating the signature. Since a txid is a hash of the transaction, any change to the transaction will result in a change of the txid. However, changes that alter the txid and invalidate the signatures are not a concern; only changes which alter the txid and do not invalidate the signature raise malleability concerns.

➤ Learn more about digital signatures.

Why Transaction Malleability Is a Problem

Malleability is a problem for developers and users who want to reference a previous transaction in a new spending transaction before the previous transaction has been confirmed on the blockchain. This problem arises because, in order to spend bitcoin created by a previous transaction, the spending transaction must reference the txid of the previous transaction. If this txid can change, the reference will fail, and the spending transaction will be rendered invalid.

Specifically, transaction malleability was a problem preventing the adoption of the Lightning Network, which relies on the exchange of unconfirmed Bitcoin transactions.

How SegWit Fixes Transaction Malleability

A transaction can be malleated in two ways. First, after a transaction is signed, additional data can be added to a ScriptSig, the part of the transaction which holds the signature and other data used to unlock the bitcoin. Secondly, the signature itself, which is contained within the ScriptSig, can be changed. These options are both possible because a signature cannot sign itself, and thus cannot make itself immutable. Since the ScriptSig and the signatures it contains are part of the txid preimage, if they are changed, the txid will change.

SegWit eliminates this possibility by removing all data from the ScriptSig. This is accomplished by moving the ScriptSig data—usually signatures and public keys—to the Witness, a new part of SegWit transactions that is not hashed to calculate the txid. The ScriptSig for SegWit inputs are thus made immutable after signing, and the data required to unlock bitcoin, which are not immutable, are contained in the Witness. This means that the ScriptSig cannot be changed, and thus the txid cannot be changed without invalidating the entire transaction.

SegWit Enables the Lightning Network

The activation of SegWit enabled the launch of the Lightning Network as a second layer on top of the Bitcoin network. Until SegWit was activated, the Lightning Network was unworkable because it relied heavily on unconfirmed bitcoin transactions and was thus susceptible to attack so long as transaction malleability was possible.

➤ Learn more about the Lightning Network.

SegWit’s Block Size Increase

Although SegWit is technically a soft fork, it altered one of Bitcoin’s important consensus rules in a backwards-compatible way in order to increase the number of transactions that could be included in each block.

Prior to SegWit, each block was limited to 1MB of data, which equates to roughly 1650 transactions in a full block. SegWit introduced block weight, which replaced block size as the limiting factor for a block. Today, full blocks contain around 2700 transactions.

Block weight is calculated in weight units. One byte of a transaction’s non-Witness data is worth 4 weight units, while one byte of Witness data is worth 1 weight unit. The block weight limit is set to 4 million weight units. Critically, for a block which only contains non-SegWit transactions, this 4 million weight unit limit would be equivalent to the old 1 million byte limit.

This new measurement method allows the block size increase to remain a soft fork, but it also gives Bitcoin miners and users financial incentives to use SegWit. Bitcoin users can save on transaction fees if they use SegWit transactions, because the Witness data takes up less of the block weight limit, and miners who include SegWit transactions can fit more transactions in their blocks, yielding higher fee revenue.

➤ Learn more about Bitcoin transaction fees.

Rationale Behind the SegWit “Witness Discount”

SegWit introduced the concept of weight units to Bitcoin. Concurrently, the upgrade specified that data stored in the new witness would count for “1” weight unit, whereas the legacy transaction fields would count for “4” weight units. Expressed differently, witness data is discounted to 0.25 versus the standard 1 for legacy data fields.

The discount factor of four helps to balance the incentives between creating an output and spending one. Prior to SegWit, it was much costlier to spend an output; this is because a standard transaction’s signatures and spending scripts contained more data than the previous output (Bytes as opposed to Bitcoin’s vBytes).

This discrepancy tended to have the effect of incentivizing users to create more outputs than they spent. If this scenario would have been allowed to play out over a sufficiently long horizon, it could have bloated Bitcoin’s UTXO Set to the point where the average user would not feasibly be able to run a node.

In order to quickly verify transactions, nodes keep a copy of the UTXO Set stored in RAM (random access memory). But, RAM is a finite resource and Bitcoin developers wanted to minimize the cost of running a node for the benefit of network decentralization. The “witness discount” accomplishes this by roughly balancing the cost of creating and spending outputs.

SegWit’s New Script Types

Script types are different ways of sending bitcoin on the blockchain using Bitcoin’s scripting language, Script. SegWit introduced two new script types in order to make use of the Witness field: Pay-to-Witness-Pubkey-Hash (P2WPKH) and Pay-to-Witness-Script-Hash (P2WSH).

Pay-to-Witness-PubKey-Hash (P2WPKH)

Prior to SegWit, a vast majority of users used Pay-to-Pubkey-Hash (P2PKH) scripts, which locked bitcoin to the hash of a public key. SegWit’s Pay-to-Witness-Pubkey-Hash (P2WPKH) functions almost identically to P2PKH, with one main difference. When users spend a P2WPKH output, the signature and public key, the two data needed to unlock a P2PKH or P2WPKH output, are stored in the Witness, while the ScriptSig is blank. As mentioned, this is done to prevent malleability of the txid.

Pay-to-Witness-Script-Hash (P2WSH)

The second most popular legacy script type is Pay-to-Script-Hash (P2SH), which allows bitcoin to be sent to the hash of an arbitrary script, called the redeemScript. This bitcoin can then be redeemed by anyone who can provide the redeemScript and fulfill the requirements specified therein.

Prior to SegWit, P2SH was most commonly used for multisig, as it saved space and privacy compared to alternatives such as bare multisig.

SegWit implemented Pay-to-Witness-Script-Hash (P2WSH), which functions similarly to P2SH. P2WSH outputs can be spent by providing the Witness Script, the SegWit equivalent of the redeemScript, and the signatures and public keys required by the Witness Script. Similar to P2WPKH inputs which leave the ScriptSig blank, P2WSH inputs must have blank ScriptSig fields and place the Script Witness–composed of the required signatures and public keys–in the witness field.

Wrapped SegWit

The introduction of two new script types was a major change to the Bitcoin protocol, and the many different wallets, applications, and services could not be expected to immediately accommodate this large change. In order to make SegWit adoption easier and more incremental, a bridge was constructed between legacy script types and SegWit script types.

This bridge is called wrapped SegWit, and it is a form of legacy P2SH script. Wrapped SegWit scripts take a native SegWit script, P2WPKH or P2WSH, and use it as the redeemScript of a P2SH script. The two types of wrapped SegWit scripts are thus P2SH-P2WPKH and P2SH-P2WSH.

This design allows older wallets and other software to send bitcoin to SegWit addresses even if they do not support SegWit. The receiver of a wrapped SegWit transaction can spend the bitcoin as a SegWit input, and thus save on fees.

SegWit’s new encoding scheme

The SegWit upgrade also introduced a new encoding scheme for SegWit addresses, called Bech32. Prior to SegWit, Bitcoin addresses and private keys had been encoded using Base58, a scheme which used both upper and lowercase letters.

Bech32 was proposed and accepted as an improvement over Base58 because it never uses mixed letter casing, making it more legible, easier to read or transcribe, and more suitable for QR encoding. Additionally, Bech32 has a built-in error detection mechanism to help users and wallets detect and even repair typos or changes to an address.

Bech32 also makes native SegWit addresses easily recognizable, as they only use lowercase letters and begin with “bc1”. Because Bech32 only uses 32 characters, these addresses are slightly longer than Base58 addresses, but they take up less space on the blockchain itself.

SegWit History and Activation

The SegWit upgrade was an extremely controversial upgrade to Bitcoin, and had a lasting impact on the development process and the community. However, Bitcoin’s success in the face of such a challenge proved to many just how resilient Bitcoin is.

SegWit was first proposed for Bitcoin Core in 2015 in order to solve transaction malleability and free up more space on the blockchain. However, during this time, members of the community were worried about Bitcoin’s ability to scale and handle a growing number of transactions.

In an attempt to scale Bitcoin, some members of the Bitcoin community proposed SegWit2x, which introduced SegWit and doubled the block weight limit to 8 weight units, equivalent to 2MB. SegWit2x gained support from 95% of miners, as measured by hash rate. Over 50 businesses in the Bitcoin industry signed an agreement called the New York Agreement, pledging to activate SegWit2x and double the block size.

The New York Agreement (NYA) was a departure from Bitcoin’s open-source consensus process.For this reason, the NYA did not receive sufficient support from node operators and developers and ultimately failed.

Instead, an anonymous, previously unheard of developer proposed BIP 148, which gained support from node operators and was able to implement SegWit while rejecting SegWit2x. In order to push this change through, many nodes adopted alternative implementations of Bitcoin Core, which forced miners to adopt SegWit or risk having their blocks rejected.

Why Node Operators Opposed SegWit2x

Node operators store the entire blockchain, and many node operators use small, low-powered machines to do so. SegWit2x would have more than doubled the rate at which the blockchain grew, forcing node operators to store a rapidly growing amount of data. This would impose costs on node operators, slow down initial block download (IBD) times, and discourage users from running a node.

Most developers also opposed SegWit2x for similar reasons. They feared that if fewer individuals could run nodes, the network would become more centralized and thus less resistant to censorship and capture.

What We Learned From SegWit

The arguments fought over SegWit and SegWit2x demonstrated that nodes, not miners, businesses, or even developers, control the network. Nodes running their own software were able to overrule an overwhelming majority of miners and implement SegWit while rejecting SegWit2x.

This inspires confidence in Bitcoin users that the consensus rules of Bitcoin, including Bitcoin’s hard cap of 21 million, cannot be changed without the consent of node operators.