Numerous proposals to solve Bitcoin have been put forward over the years. One of the more interesting concepts comes in the form of Extension Blocks. This new protocol was first proposed by the BCoin developers.
Extension Blocks Sounds Interesting
When the topic was revisited in 2017, Purse CEO Andrew Lee introduced the world to Extension Blocks. A GitHub repository was created to let developers from all over the world review the code and its implications. The concept had support from a handful of developers and Bitcoin enthusiasts.
A 2013 Concept Revisited
As is usually the case when scaling ideas come to fruition, they “borrow” some concepts from older ideas and proposals. In the case of Extension Blocks, the concept leans heavily on a 2013 proposal by Johnson Lay. His idea was to artificially increase Bitcoin’s block size of 1 MB through an auxiliary block. While the solution would require a soft fork to be introduced, it is less invasive than forcing a hard fork upon the community.
The main selling point of a soft fork is how the “political implications” are nearly non-existent. Anyone with enough hashing power on the network could help make the Extension Blocks vision come true. By utilizing this opt-in second layer of scaling, the proposal should not have faced too much opposition. No one would be forced into using this concept, unless they really wanted to.
How Does it Work?
The Extension Blocks are a separate block of Bitcoin-related information that are tethered to the end of every regular network block. In doing so, an on-chain capacity increase would be unlocked for those users who opted in to using this scaling proposal. At the time, it appeared to be a very elegant solution to one of Bitcoin’s biggest problems since its introduction in 2008.
Furthermore, the “larger blocks” would pave the way for other improvements coming to Bitcoin in the future. That list includes a transaction malleability fix, as well as building the foundation for smart contracts on top of Bitcoin’s network. Additionally, this proposal paved the way for the Lightning Network, which would be introduced through methods other than by enabling Segregated Witness.
From day one, it was evident that those who supported this concept wanted Bitcoin to achieve new levels of usability and scalability. The option to begin building smart contracts, enable the Lightning Network, and even have privacy-oriented solutions introduced at some point should have been enough selling points. The most important aspect was how this technology would be backward compatible, ensuring older Bitcoin clients could keep running on the network without any problems.
Drawbacks Hinder Adoption
No technology proposal is perfect, especially in the Bitcoin world. Researchers and developers quickly pointed out some crucial drawbacks to the Extension Blocks proposal. It was a very complex system from a technical point of view, which would make it far more complicated to implement. The backward compatibility was a nice idea, but even that raised some tough questions when put under a microscope.
Luke Dashjr, one of the Bitcoin Core developers, also voiced his concerns. He claimed that Extension Blocks would result in two different sets of full nodes running on the Bitcoin network. That would eventually cause a lot of problems for nodes and client snot opting in to this scaling proposal. Combined with how non-upgraded nodes would have to “trust” the extension blocks’ validity, it became apparent that this concept would not be introduced to the network in the near future.
The project has not received any development updates for over three years now, and is unlikely to be revisited in the near future.