Even though it sometimes appears as if we are getting closer to a bitcoin scaling solution, that is far from the case. Yet another proposal is making the rounds under the name of Segwit2MB. While many people assumed this was an April’s Fools joke at first, it appears this proposal is seemingly legitimate. If that is the case, it is a rather useless proposition, though.
SegWit2MB Is An Intriguing Concept
To put this new proposal into perspective, Segwit2MB does not necessarily seem to serve a specific purpose. Its creators want to merge this concept into bitcoin through a combination of a soft and hard fork. It will use Segwit as it is today with a 2MB block size increase in the form of a hard fork, which is set to occur at a predetermined date.
Combining a soft fork and a hard fork to appease to all bitcoin communities makes little to no sense, though. Once SegWit activates, there will be a future block size increase already. Introducing an additional hard fork to achieve this goal is counterproductive at best, which is why this proposal is met with a lot of skepticism. Even the developers admit Segwit2MB is not the best possible technical solution, which is rather intriguing.
While it is true more proposals to see SegWit getting activated is quite interesting. Then again, the UASF seems to serve that purpose just fine, assuming it will ever happen. Organizing a user-activated soft fork takes time and careful planning, though, and it poses its own set of risks and problems. There is no “clean” solution to solving this problem, although that is not exactly news either.
Some bitcoin community members express a liking toward this concept. Segwit2MB may be a bit contradictory in some regards. Then again, hard forking bitcoin is the right way forward, according to one Reddit user. Keeping bitcoin as “one currency” needs to be the top priority, that much is certain. Triggering an automatic block size increase once SegWit activates holds a lot of merit, as it would initiate a clear path of action.
Rest assured discussions like these will always be considered highly controversial. Having non-Core and non-BU developers propose such a radical solution causes a lot of mixed reactions. Hard forks should always be discussed with the economic community first. Assuming consensus can be achieved in this regard, the option can then be kicked around among all developers and then open it up to general feedback.
Header image courtesy of Shutterstock
