The Bitcoin Classic Team has released their initial roadmap proposal for 2016 that will be rolled out in three phases, including raising the block size limit from 1MB to 2MB (BIP 109) and eliminating the need for blocks to be sent within seconds after their discovery to reduce the risk of profit loss for miners.
Bitcoin Classic Roadmap 2016
The three-phase Bitcoin Classic roadmap aims to “help realize Satoshi’s vision of making Bitcoin scale into a global peer to peer cash system,” by implementing BIP 109 to raise the block size limit from 1MB to 2MB. However, the proposal will be first sent to miners, Bitcoin companies, and users for feedback so that everyone is on the same page for this potential block size solution.
One of the key strategies in the proposal aims to offset the looming drop in miner rewards by increasing the transaction volume and thus, increasing revenue for Bitcoin miners from fees. Published on Github by Olivier Janssens, the proposal explains:
We believe on-chain scaling is crucial for the long term health of Bitcoin. On-chain scaling maximizes transaction volume, whose fees are needed to replace miner rewards on the medium to long term scale.
This expected to be achieved by implementing on-chain scaling and solutions realizing continuous block syncing, which will not longer require blocks to be synced within seconds. The team hopes to do this by transmitting new block data within the full ten-minute interval between blocks instead of immediately after a new block is discovered. “This will enable the Bitcoin network to scale to significant new levels, without endangering decentralization,” the team explains.
3 Phase Approach
Phase one of the roadmap will cover the first and second quarters of 2016 with the urgent, short term solution of bumping the block size up to 2MB. This will require a Bitcoin hard fork based on Bitcoin Core implementation 0.11.2 and 0.12.0 with a 75% activation threshold or 750 of 1,000 blocks with a 28 day activation grace period.
Phase two will span the second and third quarters of the year. It will focus on eliminating the need for sending blocks within seconds to reduce “the effect of block propagation times,” i.e lost miner income from orphaned blocks. Improvements to the P2P layer are also in the works to optimize bandwidth distribution, reducing the workload on constrained Bitcoin nodes.
This phase will also attempt to “de-emphasize” increasing the block size as a solution, with greater consideration of potential “on-chain transaction throughput gains” by implementing several new changes to the code that will be finalized after further deliberation, including:
- Parallel validation of blocks (theoretically reduces the profitability of excessive-sized block attacks;
- Headers-first mining (largely nullifies excessive-sized block attacks);
- Thin blocks: Blocks refer to transactions that have been well propagated rather than including them, allowing for minimization of bandwidth use;
- Weak blocks: allow miners to pre-announce the blocks they are working on, to minimize the data sent once a block is found;
- Validate Once: Transactions that have been validated when entering a node’s memory pool do not need to be revalidated when included in a block (speeds up block validation).
Phase three (Q3, Q4) will focus on making the block size limit more “dynamic,” though only after miners and Bitcoin companies are content with the block size increase from the previous Phase. This will be carried out using a “variation” of BitPay CEO Stephen Pair’s proposal, where the “validation cost of a block must be less than a small multiple of the average cost over the last difficulty adjustment period.” In addition, the team plans to implement a simplified version of the Segregated Witness (SegWit) solution from Core after it is released.
Finally, the Bitcoin Classic team has announced that it will soon hold an on-chain scaling conference with no specific date as of yet, to discuss the proposals included in this roadmap with the Bitcoin community.
Meanwhile, Blockchain CEO, Peter Smith, tweeted his recent experience running Bitcoin Classic, albeit noting that this was a “low key” trial in an effort to “support scaling the network and solving the congestion problem.”
After a week+ of running Bitcoin classic, it's performing just as good/better than our bitcoinj, Core and btcd nodes.
— Peter Smith (@OneMorePeter) February 26, 2016
You can check out a more technical version of the Bitcoin Classic roadmap here.
What are your thoughts on this proposal? Is it a viable solution to scaling Bitcoin? Let us know in the comments below!
Images courtesy of www.progressivegrocer.com