What Is Segregated Witness (SegWit)?

12 min read

SegWit, or Segregated Witness, refers to an update that changed the transaction format in the Bitcoin protocol. Its purpose as a protocol upgrade was to protect against transaction malleability and increase block size capacity, which would enable more transactions to fit inside a block. Transaction malleability describes the risk that minor elements of transaction information can be altered, potentially invalidating new blocks. The proposal of SegWit came from Peter 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. 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 Is Transaction Malleability a Problem?

Transaction 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.

Before SegWit, transaction malleability was a problem preventing the adoption of the Lightning Network, which relies on the exchange of unconfirmed bitcoin transactions.

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.  

Comparison diagram illustrating the difference between Bitcoin blocks before and after the implementation of Segregated Witness (SegWit). The left side shows a block with legacy transactions filled with transaction data and signature data. The right side shows a block with SegWit transactions, where the signature data is separated into a distinct witness area, creating extra capacity within the main block space. This visual explains how SegWit optimizes block space usage and increases transaction capacity in the Bitcoin network.

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.

Key Fact: Before SegWit, blocks were limited to 1MB in size.
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).

Key Fact: Script types which predate SegWit, such as P2PKH and P2SH, are known as Legacy script types.
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 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.

Key Fact: Bech32 is also used to encode Lightning invoices, which begin with 'lnbc1'.
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
Not all wallets and exchanged have implemented SegWit

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.

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.

Key Takeaways

  • Segregated Witness, or SegWit, is an upgrade to Bitcoin that was activated in 2017 to fix transaction malleability and help Bitcoin scale.
  • SegWit enabled the Lightning Network to be launched on top of the Bitcoin protocol.
  • SegWit’s activation proved that Bitcoin is an antifragile system controlled by node operators, not miners or business leaders.