Block Size Debate
Satoshi’s vision of Bitcoin had no block size limit, and this was the case until the 0.3.1 version/release. The 1MB Block Size was first introduced as a measure to prevent attack vectors found in the early stages of Bitcoin, in which a malicious actor could continuously create big blocks that would take longer than 10 minutes to validate. The infamous Block Size debate can be considered as an “impossible decision” when considering the possibilities. Some believe Bitcoin should maintain the current 1MB Block Size, claiming that raising the block size will pose scalability problems regarding storage and bandwidth.
Many argue that Centralization can come as a result of these higher storage and bandwidth requirements, as the amount people with the resources to run a full node decreases. This has turned out to be a false threat, however.
Read more: http://zander.github.io/posts/Scaling%20Bitcoin/.
Since bigger blocks take longer to process and validate after said block is mined, which is counted as wasted time since it’s not being put to use building a new block, users will have an incentive to mine on the pool with the highest hash rate. Others believe that the Block Size should be changed to 2 MB, and possibly more in the future, on the premise that the current block size will not be able to support mass adoption of the cryptocurrency, since the transactions per second (TPS) are limited to 3 tps on the current 1MB Block Size system, bottlenecking the Network’s capabilities, which currently pales in comparison to payment systems like PayPal or VISA, and smaller blocks will also require higher fees as block rewards halve and the bitcoin price rises. Although there are off-chain solutions that have been presented, but there is also concerns regarding the creation of fractional reserve systems with the implementation of these solutions.
Bitcoin Classic team members argue that immediate action should be taken to deal with this problem, by implementing the Bitcoin Improvement Proposal 109 (BIP 109), in which the block size limit would be increased to 2mb. The BIP 109 was written by Classic Developer Gavin Andresen and would be implemented after a 28 day period once a 75% super majority of miners agree with the changes proposed in this BIP.
The Bitcoin Classic client acts as a voting tool for the BIP 109 implementation and it ensures that miners that are already running this client do not have to upgrade the software in case of the hard fork implementation. The 28 day time frame is considered to be long enough to allow every miner to perform the upgrade, since the current Bitcoin Core client has a built-in function that tells its operator an upgrade is required. A great deal of effort has been put into taking the opinions of major Bitcoin Companies and Mining Pools before starting the project. Comments about the options presented by the Classic Team Members shows that the majority of the people involved in the inquiry support a higher block size limit.
Bitcoin Classic proposes solutions that ensure the “wasted time” between blocks (orphan rates) in which miners will not be profiting, will not be a downside to the increased block-size.
Parallel validation of blocks Headers-first mining is two of the proposed solutions that would mitigate attack vectors found in a bigger block size limit protocol when verifying one block at a time. Classic claims that Bandwidth requirements can be reduced by implementing Weak Blocks (Blocks pre-announced by the miner that is working on it) and Thin Blocks (Blocks would refer to transactions that have been well propagated rather than including them) reducing the amount of data broadcast. In the future, Bitcoin Classic would also implement dynamic block size limits and a simplified version of the Segregated Witness soft fork project from Bitcoin Core, once It’s released. Bitcoin Classic Roadmap: https://github.com/bitcoinclassic/documentation/blob/master/roadmap/roadmap2016.md.
The hypothetical implementation of the BIP 109 should not be seen as a change from Bitcoin Core to Bitcoin Classic, but simply as a feature that would be implemented in Bitcoin by members of the Bitcoin Classic development team and agreed upon by the community. Miners will still be able to use an updated version of Bitcoin Core that will allow them to validate blocks larger than a 1MB and to stay on the right blockchain, in case a consensus to increase the block size limit is reached. In that sense, none of the teams should be seen as trying to take over one other, or bitcoin itself, in a competition. But are simply two teams that are working on different ways to achieve the same purpose, which is to ensure Bitcoin’s functionality, security and scalability.
Bitcoin Core has also presented many solutions to the scalability problem, such as Segregated Witness (separating transaction data from cryptographic signatures), Sidechains and Lightning Network. The biggest concern regarding these solutions the creation of federations and fractional reserve systems, like the ones that have lead popular Bitcoin Exchanges to ruin and continue to do so for our current banking system. None of them are released, however, while Bitcoin Classic released the 2MB change in February.
Bitcoin Classic’s main goal is, in this sense, to provide an on-chain solution to scalability and to allow users to make transactions in Bitcoin and not in Bitcoin substitutes.