Solving The Bitcoin Block Size Debate With A Two-Pronged Proposal
As much as most people would like to think otherwise, the Bitcoin block size debate is far from over. Various new proposals have been suggested in the past, and another interesting concept was posted on Reddit earlier today. According to this user, a small block size increase should be done first, followed by the integration of Segregated Witness. Addressing the key issue as soon as possible should be the top priority for all Bitcoin developers.
Two Separate Block Size Solutions Combined Into One
Based on the findings of the Reddit in question, Segregated Witness should not be the first and foremost solution to settling the Bitcoin block size debate. The reason for this is simple: Segregated Witness would split block data into two streams, which will both be stored on the user’s hard disk. As a result, Bitcoin Nodes will still be dealing with an increased block size, making this less of a favorable solution for some users.
Even though the user strongly feels Segregated Witness has its merits, Bitcoin developers have been showing a level of hypocrisy when talking about this solution. When everything’s said and done, bandwidth and disk space requirements will still increase for all parties involved, albeit in slightly smaller sizes compared to other previous proposals. By addressing this solution as a “soft fork”, Bitcoin developers hope to sway the mind of community members into making this the preferred solution.
In addition, it looks like Segregated Witness is more about fixing the transaction malleability system than having to do with the Bitcoin block size debate. While it is important to address transaction malleability sooner rather than later, a solution has to be found to solve the block size debate at the same time, without resorting to the semantic game.
There is no reason a small block size increase can’t be done – it takes a minor alteration to the existing code – and implement Segregated Witness afterward. Keeping in mind how a small block size increase has nearly identical disk footprint requirements compared to segwit, and can be implemented in a much shorter time frame, this approach seems to have a certain merit.
Segregated Witness Needs To Be Tested And Vetted
Even though Segregated Witness is a valid solution, testing and vetting the code base will take weeks, if not months, to complete. Increasing the Bitcoin block size itself is a more pressing matter, as this issue has been kicked around for far too long already. Increasing the block size soonish, and implementing segwit after the vetting process seems to be a smart approach.
Based on the Reddit feedback so far, a lot of Bitcoin community members see the benefits of this two-pronged approach. After all, decisions like these rely on reaching consensus among the bitcoin community. Whether or not the Bitcoin developers will keep this proposal in mind, remains to be seen, though.
What are your thoughts on this block size proposal? Are you in favor of doing things in two different phases? Let us know in the comments below!
Images courtesy of Shutterstock, Peak Usability