What Is SegWit (Segregated Witness)?

Ever wanted to upgrade your current computer? To make your old computer noticeably faster at a minimal cost by adding RAM, for example?

Complex software such as Bitcoin can also be upgraded. Making some major upgrade to a system while maintaining backward compatibility is often referred to as a soft fork.

Segregated Witness (often shortened to SegWit) is an essential historical upgrade to bitcoin’s protocol, its soft fork. This update was successfully activated in Bitcoin in 2017. SegWit improved several aspects of Bitcoin, such as the speed and scalability of the network, and opened the door for further updates, including Taproot.

In this article, we will discuss SegWit in detail, why it is crucial, and what opportunities it provides for an updated Bitcoin.

What Is SegWit (Segregated Witness)?

Segwit is an acronym for Segregated Witness. Segwit is a blockchain protocol update developed for bitcoin and several other cryptocurrencies.

Its main goal was to solve two problems: scalability and transaction plasticity. With the first problem, everything is more straightforward: scalability is responsible for the total volume of transactions performed in a certain period. The plasticity problem will be dealt with in more detail later, as it is the critical factor that allows us to understand what Segwit is all about.

Attempts to solve the plasticity problem began in the first half of the 2010s. Still, the cryptocurrency community could not agree on a single mechanism for changing bitcoin’s source code for a long time. As a result, the vast majority decided to accept the implementation of Segwit technology.

The activation of this update was done in stages and faced several difficulties. Some parts of the community never accepted this update, which led to the emergence of new cryptocurrencies (now altcoins).

After a general introduction, we are ready to move on to the technical details of this upgrade.

What is transaction plasticity?

To understand how Segwit works, it is essential to know what transaction plasticity is. So let’s begin our dive into the question with some preliminary theoretical background.

Transaction plasticity is the ability of a transaction to have more than one valid txid. Plasticity occurs when part of a transaction can be changed after it has been signed without invalidating the signature.

Since the txid represents the transaction’s hash, any change to the transaction will cause its txid to change. However, changes that change the txid and invalidate the signature are not the real problem — only those changes that change the txid but do not invalidate the transaction’s signature create a real plasticity problem.

So, transaction plasticity is a problem for developers and advanced users who, in a new spending transaction, want to reference a previous transaction before it has been validated in the blockchain. The problem arises because to use the output created by the earlier transaction; the spending transaction must reference the txid of the previous transaction.

If the txid of the previous transaction is changed, the reference will become invalid, and the new spending transaction will be invalidated.

In particular, it is a problem of transaction plasticity that has hindered the successful implementation of the Lightning Network, which for the most part, is based on the exchange of bitcoin transactions that are unconfirmed by the onchain.

How exactly does SegWit solve the transaction plasticity problem?

The plasticity problem can be solved in two ways:

• First, once a transaction is signed, additional data can be added to scriptSig (the part of the transaction that contains the signature and other data used to unlock bitcoins).
• Second, the signature itself contained in the scriptSig can be changed.

Both options are possible because the signature cannot validate itself and thus cannot ensure its immutability. Since scriptSig and its signatures are part of the txid prototype, the txid will also change if they change.

SegWit eliminates this possibility by removing all data from the scriptSig. This is accomplished by moving scriptSig data (usually signatures and public keys) to witness. This is a new part of SegWit transactions that is not hashed when calculating the txid.

Thus, the scriptSig for SegWit inputs after the transaction is signed becomes immutable, and the data needed to unlock bitcoins that are not immutable is contained in the witness section. In this configuration, scriptSig cannot be changed; thus, the txid cannot be changed without invalidating the entire transaction.

Why did SegWit make the Lightning Network possible?

The activation of SegWit enabled the Lightning Network, a vital Layer 2 protocol that runs on top of the Bitcoin network.

Before SegWit was activated, this was impossible because the Lightning Network relied heavily on unconfirmed bitcoin transactions, and plastic transactions would open the door to attacking the network.

How did SegWit increase block size?

The following most crucial change is the increase in bitcoin block size. In a nutshell, it was done to speed up the passing of transactions on the network. Next, we will talk about how this was technically implemented.

Before SegWit was activated, each block was limited to 1 MB, corresponding to about 1,650 transactions in a full block. With SegWit, the concept of block weight was introduced, which changed the block size as a limiting factor. Today full blocks contain about 2,700 transactions.

Segwit didn’t just increase the block size; it allows the block size to be increased in a backward-compatible way so that upgrades can be implemented via a soft fork without resorting to a hard fork.

The new method also creates a financial incentive for Bitcoin miners and users to use SegWit specifically. Users sending SegWit transactions can save on commissions because less block weight is consumed. Miners including SegWit transactions in their blocks can fit more transactions into their blocks, thereby increasing revenue from commissions.

What is the new address encoding scheme in SegWit?

The SegWit update also introduced a new encoding scheme for SegWit-addresses, called bech32. Before SegWit, bitcoin addresses and secret keys were encoded using the Base58 scheme, which uses lowercase and uppercase letters.

Bech32 was proposed and accepted as an improvement over Base58 because it never uses mixed case characters, making it easier to read or decode and more suitable for QR-coding.

In addition, bech32 has a built-in error detection mechanism to help users and wallets detect and correct typos or changes in bitcoin addresses. Bech32 also makes native SegWit-addresses easily recognizable because they start with bc1 and only use lowercase letters.

Because bech32 uses only 32 letters of the alphabet, these addresses are slightly longer than Base58 encoded addresses, but they take up less space in the blockchain.

What are the new script types in SegWit?

Script types are different ways to automate and send bitcoins across the blockchain using the Bitcoin Script language. With the introduction of the witness field in the transaction, two new script types were introduced: Pay-to-Witness-Pubkey-Hash (P2WPKH) and Pay-to-Witness-Script-Hash (P2WSH). Let’s discuss them in more detail.

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

Before SegWit, most users used Pay-to-Pubkey-Hash (P2PKH) scripts that bind bitcoins to a public key hash.

The functionality of the new Pay-to-Witness-Pubkey-Hash (P2WPKH) introduced with SegWit is almost identical to P2PKH, with one crucial difference. When users expend the P2WPKH output, the signature and public key (the two data points needed to unlock P2PKH and P2WPKH outputs) are stored in the witness field, while scriptSig is left blank. As mentioned above, this is done to prevent plasticity of the txid.

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

The second most popular old type of script is Pay-to-Script-Hash (P2SH), which allows bitcoins to be tied to a hash of an arbitrary script called a redeemScript. These bitcoins can then be unlocked by anyone who can submit an appropriate redeemScript and meet the requirements specified therein.

Before SegWit, P2SH was most often used in multisignatures because it saved space compared to alternatives such as simple multisig.

SegWit implements Pay-to-Witness-Script-Hash (P2WSH), which functions similarly to P2SH. P2WSH outputs can be consumed by providing a witnessScript (the SegWit equivalent of redeemScript) and the signatures and public keys defined in the witnessScript.

What is Wrapped SegWit?

Implementing two new types of scripts was a significant innovation in the Bitcoin protocol. One would hardly expect many different wallets, applications, and services to adjust to this significant change immediately.

To make SegWit implementation more accessible and gradual, a bridge was built between legacy script types and SegWit script types. This bridge is called Wrapped SegWit and is a form of the old P2SH script.

Wrapped SegWit scripts take the native SegWit script, P2WPKH, or P2WSH and use it as the redeemScript for the P2SH script. Thus, the two types of Wrapped SegWit scripts are P2SH-P2WPKH and P2SH-P2WSH.

This design allows legacy wallets and other software to send bitcoins to SegWit-addresses, even if they do not support SegWit. The recipient of a Wrapped SegWit transaction can spend the bitcoins as SegWit input and therefore save on fees.

What are the advantages and downsides of SegWit?

To understand the pros and cons of this implementation, we need to tell the story of the search for the best way to expand bitcoin. The SegWit update has been highly controversial and has had a lasting impact on Bitcoin’s development process and its community.

However, Bitcoin’s success in facing such a challenge has been proof of the project’s sustainability. SegWit was first proposed for Bitcoin Core in 2015 to address transaction plasticity and free up more blockchain space.

At the time, the Bitcoin community was concerned about Bitcoin’s ability to scale and process a growing number of transactions. Bitcoin could become a victim of its popularity; even then, the network was already operating at its limits.

In an attempt to scale Bitcoin, some community members proposed an update to Segwit2x, which involved introducing SegWit support and doubling the block weight limit to 8 wu, equivalent to 2 MB. SegWit2x received 95% support from miners.

More than 50 big companies from the bitcoin industry signed the so-called New York Agreement, committing to activate Segwit2x and double the block size. The New York agreement was a departure from Bitcoin’s open consensus process and, for that reason, did not receive enough support from node operators and developers, finally failing.

Instead, an anonymous, previously unknown developer put forward BIP 148, which gained the support of node operators and successfully activated SegWit, explicitly rejecting Segwit2x. To promote this change, many nodes adopted alternative implementations of Bitcoin Core, forcing miners to adopt SegWit in the face of the risk of their blocks being rejected by the network.

Therefore, the history of SegWit implementation has been quite controversial and full of opposition, with much discussion and controversy preceding the activation itself. 

So why have node operators opposed Segwit2x?

Node operators store a full copy of the blockchain; many use small, low-power machines. Activating Segwit2x would more than double the growth rate of the blockchain, forcing operators to store a rapidly growing volume of data.

This would have increased costs for node operators, slowed initial blockchain loading, and discouraged users from running their nodes. This was a significant disadvantage of SegWit2x.

Most developers also opposed SegWit2x for similar reasons. They feared that if fewer people could run a node, the network might become more centralized and less resistant to censorship and hijacking.

How to summarize the results of this update?

The SegWit technology is a noteworthy upgrade to the bitcoin network in 2016-17 to solve transaction plasticity and scalability problems.

Portal p2sh.info, which tracks the Bitcoin network’s real-time performance, reports that the total volume of transactions that have been sent using SegWit technology is currently around 80%. So, after five years, we can confidently say that the technology has caught on and been adopted by the community.

This update proved very effective and significantly improved transaction security and processing speed. The activation of SegWit was accompanied by numerous debates, which resulted in a split in the community and the formation of some new cryptocurrencies (e.g., Bitcoin Cash).

Nevertheless, the technology gained a foothold and is now used in bitcoin and other coins (the most famous among them is Litecoin).