Bitcoin Classic 2016 Scaling Roadmap

Note: This is the initial version of the proposed roadmap. The Bitcoin Classic development team will seek feedback from Bitcoin miners, companies, and users before finalizing it.

Bitcoin Classic 2016 Roadmap

The Bitcoin Classic development team is willing to help Satoshi Nakamoto realize his vision of expanding Bitcoin into a global peer-to-peer cash system, not just a settlement network. Bitcoin Classic believes that on-chain expansion will be key to the long-term health of Bitcoin. On-chain expansion will maximize transaction volume, and in the long run, these fees will eventually replace miner rewards.

The on-chain expansion strategy chosen by Bitcoin Classic is to eliminate the need for fast synchronization of blocks. Bitcoin Classic will implement a solution that makes continuous block synchronization possible. Instead of transmitting data all at once to a new block (when a new block is found), we can significantly optimize the current bandwidth by sending data between every ten-minute block interval. This will allow the Bitcoin network to significantly scale to a new level without jeopardizing decentralization. Bitcoin Classic will scale in three stages:

Phase 1 (Q1-Q2)

Urgently solve the problem of blocks being almost full

1. Implement BIP 109 : Increase the Bitcoin block size from 1MB to 2MB;

2. The hard fork activation threshold is 75% (750 votes out of 1,000 consecutive blocks), after which there is a 28-day activation grace period;

3. The software is based on Bitcoin Core versions 0.11.2 and 0.12.0;

Note: 0.11.2 has been completed and can be downloaded here.

Phase 2 (Second Quarter - Third Quarter)

Eliminates the need for blocks to be sent within seconds

1. Reduce the impact of block transfer time on orphan block rate (causing miners to lose revenue).

2. Instead of emphasizing block size as a barrier to scaling, some improvements (as shown below) are used to open up potential on-chain transaction throughput gains.

3. Optimize bandwidth-limited nodes by improving the P2P layer.

Note: Bitcoin Classic intends to discuss various solutions, such as those listed below, and select the best one.

1. Parallel validation of blocks (theoretically reducing the profitability of overly large block attacks).

2. Headers-first mining (mainly offsets overly large block attacks).

3. Thin blocks: Blocks tend to include transactions that are well-propagated rather than all of them, allowing for minimal bandwidth usage.

4. Weak blocks: Allow miners to pre-announce the blocks they are working on, minimizing the data generated when the blocks are discovered.

5. Validate Once: Once a transaction has been verified, it does not need to be re-verified when it enters the memory pool of a node (speeding up block verification).

Phase 3 (Q3-Q4)

Implementing dynamic block size limit

Note: This phase will only take place if miners and companies successfully address their concerns about block size during Phase 2 confirmation.

1. Using a variation of the scheme proposed by Stephen Pair (BitPay), the cost of verifying a block must be less than a small multiple of the average cost over past difficulty adjustment periods.

2. Implement a simplified version of Core's Segregated Witness when it becomes available.

Technical details:

More technical details about the roadmap can be found here.

Meeting

The Bitcoin Classic team plans to hold an on-chain scaling meeting soon to discuss these and future scaling solutions and related issues with the community.

Original text: https://github.com/bitcoinclassic/documentation/blob/master/roadmap/roadmap2016.md
Author: ojanssens
Compiled by: Satuoxi
Source (translation): Babbitt Information (http://www.8btc.com/bitcoin-classic-2016)