The Segwit (Segregated Witness) protocol was proposed in BIP141 as a UASF(User Activated Soft Fork) for Bitcoin (BTC). The purpose of Segwit was to enable a way to address what is called the transaction malleability problem and to implement an update to allow more transactions per block without changing the main block size. It does this by creating a sidechain alongside the main chain that is linked by the Merkle root of the blockchain. This proves that the data belongs to the block by its hashes.  Segwit also addresses security concerns around malleability. This would be to separate the signature from the transaction and put it into a space within the block header next to the coinbase field.

Developers also proposed Segwit to address the blockchain size limitation problem which reduces transaction speed (i.e. transaction velocity) on the network. To resolve this, the transaction is split into two segments, removing the unlocking signature called the "witness" data from the transaction. It is instead appended at the block header where the coinbase field is located.  The header would continue to store the sender and receiver data, along with a new data field that contains scripts and signatures. This helps to reduce signature size of the block by implementing the signature as a separate data structure on a sidechain, and this allows the block to hold more transactions. Prior to Segwit, the transactions consumed 65% of the block space.

Transaction Malleability

The transaction malleability problem stems from the ability to modify a signature in the transaction before it is validated. Transactions are packaged into blocks and first sent to the mempool on a Bitcoin node on the network. The mempool is located in the main memory of the node, and this is where blocks are stored before being committed to the blockchain. While the block is in the mempool, it can still be accessed and is open or vulnerable to modification. The signature in the transaction field can be changed, and this in turn also changes the transaction ID.

That can lead to fraud if executed by a bad actor. Suppose you sent 1 Bitcoin to another user, your signature is attached to that transaction. If your signature is removed, it is like you never spent the Bitcoin sent. To prevent this from happening, the signature was separated from the actual transaction. 

Here is a theoretical scenario of the transaction malleability problem:

Bob requests 2 BTC from Alice. Alice creates a transaction to send Bob 2 BTC. The BTC will be taken from Alice's last outputs to be spent as input to Bob’s public address. The transaction is sent out over the network and received by miners for approval. During this time, the transaction will sit in queue on the mempool. If Bob were a bad actor he can use transaction malleability to alter Alice’s signature and change the transaction ID. If Bob is successful, he can take Alice's 2 BTC but tell her he has not received it. Alice will check and see that the 2 BTC were not sent, so she will send another 2 BTC to Bob. Now Bob has 4 BTC.

Segwit resolves the problem of transaction malleability by:

• Arranging the signature data in a sidechain in the form of a Merkle Tree.
• Storing the signature data in a new part of the block.

Figure 1. A Merkle tree is a data structure, in which transactions are linked to their signature using hashes.

This would prevent any tampering from taking place, since now the signatures are no longer attached to the transaction. It will be cryptographically linked via the Merkle Tree, which is a cryptographic hash that is used on the sidechain for quick verification.

The idea did not sit well with all of the Bitcoin community. There was a faction (that would later become the proponents of Bitcoin Cash) that supported a different solution to the malleability problem called flextrans.

The Block Size Issue

The community was also divided by the block size limitation in Bitcoin of 1 MB. Opponents did not accept Segwit as a solution, because it was merely extending the block to accommodate new data but not actually increasing the size of the main block's body. Instead they opted for a larger block size that is greater than 1 MB.

This divergence in viewpoint would lead to a split in the Bitcoin community. That would lead to a hard fork that would become Bitcoin Cash in August 2017. Bitcoin continued on with the acceptance of Segwit among its supporters and it was activated on August 24, 2017. 

Figure 2. This shows the block before Segwit and after Segwit implementation.

List of Segwit related BIPs:

• BIP141 Segregated Witness (Consensus layer) – activated on 24 August 2017
• BIP143 Transaction Signature Verification for Version 0 Witness Program – activated on 24 August 2017
• BIP144 Segregated Witness (Peer Services) – activated on 24 August 2017
• BIP148 Mandatory activation of segwit deployment – activated (mandated the activation of BIP141, 143, 144)

Benefits Of Segwit

While the users are not the ones who need to implement Segwit, it benefits them and the entire community. As a soft fork, it does not have to be installed for the Bitcoin application to continue working which means it is not mandatory. The reason for installing it are the benefits in improving security and providing a scaling solution. By implementing Segwit, transaction malleability problems are prevented and more transactions can be processed in a single block. If security and scaling are an important concern, then implementing Segwit should be performed. 

A big benefit of Segwit is the support for Layer 2 scaling solutions like the Lightning Network. Since this supports off-chain payments, more transactions can be processed thus increasing the velocity of the network. This would allow Bitcoin transactions to be conducted off-chain, but settlement will go back on-chain to the main network. With this type of support, Bitcoin could increase beyond 7 TPS (transactions per second).

Another major benefit to the users of Bitcoin are lower fees. Since Segwit allows more transactions in each block, it leads to lower costs per block. A wallet that uses a Segwit address pays less compared to a non-Segwit address. The transactions are generally 25 to 40 percent lower. There have been reports in the past that Segwit will help lower fees, but that also affects business revenues. For businesses it is the ability to handle larger workloads and volumes of transactions. This should increase revenues in the long run.

Synopsis

During the first week of October 2017, the use of SegWit in transactions rose from 7% to 10%. It gradually began increasing and by February 2020 it reached 60%. Adoption has since remained steady even during the start of the 2021 Bitcoin bull run cycle. 71% of Bitcoin transactions use a Segwit address according to data (The data is subject to change). With all the benefits from Segwit, it seems that adoption should have further increased. While there are debates regarding that, the implementation of Segwit remains with node operators.