What Is Segregated Witness (SegWit)?

SegWit, or Segregated Witness, was a protocol upgrade to Bitcoin that changed how transactions are formatted. It aimed to fix issues with transaction malleability, where minor changes to transaction data could disrupt the blockchain. By resolving this problem, SegWit also increased block size capacity, allowing more transactions to fit inside each block. This enhancement leads to faster processing times and potentially lower transaction fees.

A SegWit address starts with either “3” or with “bc1”. It offers better protection as well as lower fees by taking up less block space.

The proposal of SegWit came from Pieter Wuille in 2015, and it was successfully activated in Bitcoin Core by 2017.

In this article, we explain what SegWit means for Bitcoin and how it paved the way for future innovations such as Taproot and Lightning.

How Does SegWit Fix Transaction Malleability?

SegWit fixes transaction malleability by separating signatures from the transaction data. 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 that 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. In other words, changes to the signature data no longer affect the transaction’s hash.

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.

How Did SegWit Increase the Block Size?

To increase the block size, SegWit introduced the concept of block weight as a new way to measure the size of transaction data. This enabled the network to include more transactions within each block without directly increasing the block size limit. Thus, SegWit was technically a soft fork because it altered one of the most important consensus rules in a backward-compatible way.  

Prior to SegWit, each block was limited to 1MB of data, which equates to roughly 1,650 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 2,700 transactions.

Block size is a measure of the total number of bytes in a transaction. Before SegWit, this limit was set to 1MB, or 1 million bytes.

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 had 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

SegWit introduced two new script types, which are different ways of sending bitcoin on the blockchain using Bitcoin’s scripting language, Script. SegWit introduced 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).

Script types which predate SegWit, such as P2PKH and P2SH, are known as Legacy script types.

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. Functioning almost identically, SegWit introduced Pay-to-Witness-Pubkey-Hash (P2WPKH). The main difference was that when users spend a P2WPKH output, the signature and public key are store in the Witness. The ScriptSig is left blank in order 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.

What Is Bech32?

SegWit also introduced a new encoding scheme called Bech32. Prior to SegWit, Bitcoin addresses and private keys had been encoded using Base58, a scheme that 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 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.

Bech32 is also used to encode Lightning invoices, which begin with 'lnbc1'.

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 as BIP141 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.

Since its activation, SegWit adoption has been steadily increasing. 

Not all wallets and exchanged have implemented SegWit

Why Did Node Operators Oppose 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.

How Do I Know if My Bitcoin Address Is Segwit?

Today, many Bitcoin wallets support SegWit by default. Bitcoin SegWit addresses typically start with a “3” or “bc1”.

• Addresses starting with “3” are known as Pay to Script Hash (P2SH), which supports SegWit.
• Addresses that begin with “bc1” are Bech32 addresses and represent native SegWit addresses that fully utilize the SegWit efficiency improvements. 

If your address starts with “1”, it’s a legacy address and does not support SegWit.

Can I Send BTC to a SegWit Address?

You can send BTC to a SegWit address from both legacy and SegWit addresses. The Bitcoin network supports transactions between different types of addresses to maintain compatibility and ensure users can send and receive Bitcoin regardless of the address format they use.

Should I Choose SegWit or Native SegWit?

Choosing between SegWit and native SegWit (Bech32) depends on your needs:

• SegWit (P2SH): Offers compatibility with services that may not yet support Bech32 addresses but still provides some benefits of SegWit such as reduced fees and increased transaction capacity.
• Native SegWit (Bech32): Provides all the benefits of SegWit, including even lower fees and potentially faster transaction confirmations due to its efficiency. However, it’s less widely supported by older wallets and services.

If you prioritize maximum compatibility, SegWit (P2SH) might be the better choice. For the lowest fees and if you mostly interact with platforms that support it, native SegWit (Bech32) is preferable.

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.

Economic Impact of SegWit

SegWit’s introduction has had significant economic implications for the Bitcoin network, particularly concerning transaction fees and miner revenues. By allowing more transactions to be included in each block, SegWit effectively increased the throughput of the network without the need for a hard fork.

This increase in capacity has led to a reduction in transaction fees. The increased block capacity allows for more transactions per block, which can lead to higher total transaction fees collected per block. Miners will be incentivized to maximize the block weight as profits increase with block weight.