Lightning Creator: Why Segwit is a Real Blocksize Increase Solution

In an online bitcoin community, Thaddeus Dryja, the co-author of Lightning, explained how he realized Segregated Witness (Segwit) is an actual block size increase for the bitcoin network.

Over the past few months, the bitcoin community has seen many experts including Andreas Antonopoulos and Coinbase Director of Engineering Charlie Lee, express their optimism towards Segwit, not only for its scalability but its ability to open opportunities for two-layer solutions like Lightning and TumbleBit.

Two counterarguments frequently emerged in online bitcoin communities and forums. The first was that Segwit imposes significant changes on the layer 1 infrastructure of bitcoin and that it doesn’t necessarily present immediate scalability unlike hard forks or other proposals like Bitcoin Unlimited. The second argument falsely misrepresented technical aspects of Segwit, claiming that it doesn’t actually increase block size but it creates a new storage unit which wasn’t seen in bitcoin before.

Dryja, who co-authored the first whitepaper of Lightning with Joseph Poon, admitted that as a coder, the phrase “Segregated Witness” initially led him to visualize Segwit as a solution which virtually creates another element that previously did not exist within the bitcoin network.

However, almost immediately after observing the coding behind Segwit, Dryja realized that Segwit doesn’t add a new element but really introduces bigger blocks. Upon running various tests on testnet, a server utilized by developers to experiment with new solutions, Dryja wrote:

“First day I started coding (re-implementing segwit in golang from the BIPs without looking at the c++ code) I realized, nope, that’s not how it works. The “witness block” has everything, including witnesses. The new software doesn’t touch non-witness blocks. The blocks are bigger.”

To put it simply, Dryja sees Segwit as an unambiguous block size increase proposal with a slightly different proposition in conntrast to other hard forks or solutions introduced in the past.

In late November of 2016, BitFury chief information officer (CIO) Alex Petrov shared a discovery with WhalePanda who drafted “Segwit ELI5 Misinformation FAQ.” The blog post featured a research paper shared by Petrov and the BitFury Analytics team, who discovered that the average block size with Segwit activated would reach 2.1 MB.

During his testnet experiments, Dryja discovered that his script which spammed the testnet formed 3.7 MB blocks with similar structures to old blocks. Single blocks of 3.7 MB are 3.7 times larger than current blocks and are larger than the block size agreement of 2 MB set at Hong Kong bitcoin roundtable consensus agreement last year.

“I have a script that will spam testnet and make 3.7MB blocks. It’s not a 800KB regular block with txids and output scripts, and a 2.9MB witness block with just a bunch of signatures. It’s a single block, that looks pretty much the same as old blocks with a few extra requirements, that’s 3.7MB,” explained Dryja.

It is important to consider the agreement established at the Hong Kong roundtable consensus event as several mining pools and bitcoin companies like HaoBTC still want to see hard forks to increase the block size to 2 MB. The counterargument to the claims of these mining pools is that Segwit expands blocks to a larger size than 2 MB with a more cautious and less-risk approach in a soft fork.

Image Via: WPU

If you liked this article, follow us on Twitter @themerklenews and make sure to subscribe to our newsletter to receive the latest bitcoin, cryptocurrency, and technology news.