5
Bitcoin: Back to the basics
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
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.
Classic
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.
Classic Roadmap
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.
Click here to see the Bitcoin Classic Roadmap
Blockchain news