Are you a Bitcoin or blockchain developer? You are probably looking at scalability, network latency, transaction fees, and similar issues, trying to improve public blockchains. The Bitcoin SegWit implementation has important lessons, and I will explain this project in this article. However, I will first explain what Segregated Witness (SegWit) is.

Want to know more about the Bitcoins? Enroll now: Getting Started with Bitcoin Technology

Bitcoin adoption and challenges that users face

Bitcoin has put power into the hands of people with their disintermediated and secure network and enjoys high popularity. However, you still aren’t buying your morning cuppa with it, are you?

Despite popularity, day-to-day transactions still aren’t in Bitcoin, due to the following challenges:

  1. Every node in the Bitcoin network must store all blocks and transactions, and participate in the transaction validation. A Bitcoin network can only be as fast as the slowest node. Bitcoin uses the ‘Proof of Work’ (POW) consensus algorithm that mandates the participation of every node. Read more about the POW algorithm in “PoW Vs. PoS: A Comparison Between Two Blockchain Consensus Algorithms“.
  2. POW algorithm requires Bitcoin miners to solve an increasingly complex cryptographic puzzle, hence they use heavy computing power. This increases the network load, besides it’s highly energy-intensive. The effect is network latency.
  3. Bitcoin users want their transactions to go through fast. However, network latency and lack of scalability slow them down. Bitcoin blocks can handle only a limited number of transactions, and to prioritize their transactions, users pay high miner fees. These fees kept increasing.

Bitcoin SegWit solved the transaction fees issue to a significant extent, but it originated due to another issue, which I will explain now.

Origin of Bitcoin SegWit: Bitcoin malleability

Bitcoin also had another potentially serious issue. Bitcoin uses data encryption, which first converts a plaintext into a scrambled ‘ciphertext’. Only the person with the private key can decrypt the ciphertext back into the original plaintext using the private key.

Malleability is a bug in an encryption technology that allows cyber attackers to convert the ciphertext into another ciphertext. Hackers can then decrypt the modified ciphertext into a completely different, but related, plaintext. For e.g., they can change the recipient address and payment amount in a payment transaction! Bitcoin encryption had this malleability bug.

“Segregated Witness (Consensus Layer)”, i.e. SegWit ‘Bitcoin Improvement Proposal’ (BIP) 141 was about resolving this malleability bug.

How Bitcoin SegWit implementation resolved the malleability issue

Bitcoin developer Peter Wiulle came up with the SegWit proposal in December 2015. The solution worked as follows:

  1. It created a different structure called the “Witness”. This has data for authenticating a transaction but doesn’t have the transaction details.
  2. The new Witness structure is committed to the Bitcoin block separately from the rest of the transaction data, hence the name “Segregated Witness”.
  3. Suppose hackers get hold of the transaction data and try to exploit the malleability bug. They can’t access the digital signature piece anymore with SegWit.
  4. Hence, even if they manage to change the ciphertext to something different, their effort isn’t useful without the digital signature.

This is how the Bitcoin SegWit proposal planned to resolve the malleability bug. However, the proposal included more changes, and these contributed to an effective increase of the Bitcoin blocksize. Read on, to find out how.

Bitcoin SegWit effectively increases the Bitcoin block size

Bitcoin block size is 1 Megabyte (MB). Also, the signature information constituted a good part of a transaction data, hence a block could include only a few transactions.

The SegWit proposal created a different parameter called the “Weight Unit” (WU). Each byte of the transaction data part of the block corresponds to 4 WUs. However, each byte of the “Witness” structure equals to 1 WU.

The proposal also defined the maximum weight of a Bitcoin block as 4 million WUs. Do your simple math, and you can see how the new blocks with SegWit have more than 1 MB size effectively! This allowed miners to include more transactions in a block.

Since each block now has more effective space, the fierce competition for including a transaction in a block reduces. This, in turn, reduces the transaction fees!

Had the Bitcoin community decided to overrule the 1 MB block size limit explicitly, they needed to implement a hard fork. However, crypto communities often don’t prefer hard forks due to the instability they bring to the overall network and ecosystem.

In case of the Bitcoin SegWit implementation, the rule of 1 MB block size limit remained in place, however, the new WU parameter bypassed it. Hence, there was no hard fork to implement SegWit.

Bitcoin SegWit pros and cons, and adoption

You just saw how SegWit resolved the malleability bug and reduced Bitcoin transaction fees. However, there are added benefits. Consider the example of the “Lightning Network”.

The Lightning Network is an off-chain solution to enable small, frequent payment transactions. This runs on top of the Bitcoin blockchain and doesn’t record every transaction there. This solution records only a periodic summary of transactions in the Bitcoin blockchain.

Since the system doesn’t commit all intermediate transactions in the Bitcoin blockchain, users needed confidence that their intermediate transactions were secure. The malleability bug wouldn’t allow that confidence. The Bitcoin SegWit implementation helped the Lightning Network development too.

Despite the many benefits of SegWit, you shouldn’t consider it as an advanced Bitcoin scaling solution. This isn’t an automated scalability measure, it was a one-time bypassing of the Bitcoin block size limit only. Besides, an effective increase in block size may make slower nodes take longer to load Bitcoin blocks in the future.

Bitcoin SegWit was implemented in August 2017, after many debates in the Bitcoin community over its’ pros and cons. However, the adoption is far from complete, and you can view the statistics here.

As a Bitcoin or blockchain developer, you can find important lessons from the Bitcoin SegWit implementation. Consider long-term scalability, security, and decentralization aspects when you develop your improvement proposals.