Block size debate, who is not familiar with it? The arguments are slowly cooling down as most of the Bitcoin community is favoring Bitcoin Classic. Bitcoin Classic proposes an increase in the block size from 1 MB to 2 MB to accommodate growing transactions on the Bitcoin network.
Bitcoin Classic calls for a hard fork in the blockchain to introduce the change in block size. Recently in an email, Gavin Andresen has called for constructive feedback for his variation of Jeff Garzik’s BIP-102. BIP-102 was proposed by Jeff Garzik, one of the few Bitcoin Core developers last year. Like Bitcoin Classic, BIP-102 also calls for a 1 MB increase in block size.
While asking for feedback on the modified BIP-102 proposal, Gavin Andresen provides insights to his rationale behind certain points made in the proposal. In an ordinary circumstance, increasing the block size is not a very big deal. Making a small change in the code, where maximum block size limit is changed by 1 MB to 2 MB should do the trick. However, in reality especially with lots of people relying on the blockchain for bitcoin transactions and miners constantly working to process these transactions while they search for new blocks makes such a simple modification impossible. In order to make the transition as smooth as possible, a series of codes needs to be modified and tested multiple times for any bugs that can potentially break the Bitcoin network.
Testing and Implementation
Gavin Andresen lists the various steps taken to make the transition possible. He has also included few code snippets inside the post. These code snippets include “code testing codes”, which are available in two different levels. The first level, using C++ to test the behavior of the entire code and the second level in Python for conducting regression tests.
The new changes to blockchain codes are tested thoroughly using electronic means. Even after conducting all the tests, the new block size will not come into effect until over 75 percent of the mining community (in terms of hashing power) give their approval by mining blocks with special bit-set. Once 75 percent consensus is reached, the new proposal will be implemented within the next 28 days. Gavin Andresen’s proposal has an expiry date of 1 January, 2018. If consensus is not reached within that period, the proposal will stand withdrawn.
The hash-rate threshold for Gavin Andresen’s BIP-102 derived proposal is kept at 75% and not 95% (as many would want it to be) to prevent any one individual mining pool from vetoing against the implementation at any time. Once the new block size limit is implemented, the mining community will get 28 days to make necessary changes to the software and hardware so that they can continue mining when the transition happens.
Some of the other changes proposed by Gavin Andresen includes limitations on signature operations to prevent CPU exhaustion attacks and more. The whole list of changes are available at this link.
