Bitcoin Roundtable reaches consensus on capacity expansion

Consensus text:

On February 21, 2016, at Hong Kong’s Cyberport, representatives from the Bitcoin industry and development community agreed on the following points:
We agree that Segregated Witness will continue to be actively developed via a soft fork, and is expected to be released as scheduled within the next two months.
We will continue to work with the entire Bitcoin development community to publicly develop a safe hard fork based on the SegWit improvements. The Bitcoin Core contributors attending the Bitcoin Roundtable agreed to implement such a hard fork within three months of the release of SegWit and submit it as a proposal to Bitcoin Core.
This hard fork should include some features that are being discussed in the technical community, including: increasing the non-witness data to about 2MB, and the total size does not exceed 4MB. This hard fork will only be implemented if it is widely supported by the entire Bitcoin community.
We will not run SegWit in production until Bitcoin Core releases a version that includes the hard fork code above.
For the foreseeable future, we will only run systems that are compatible with the Bitcoin Core consensus protocol, which will eventually include SegWit and the hard forks mentioned above.
We have been working on developing scaling technologies that can use block space more efficiently, such as Schnorr multi-signature.
Based on the above, the estimated time nodes are as follows:
In April 2016, Segregated Witness was released;
In July 2016, the hard fork code was developed and available for use;
In July 2017, if it can gain broad support from the community, the hard fork will take effect.

This is an important consensus reached by Chinese miners who account for 70% of the total network computing power and Bitcoin core developers. It is a great consensus, and it is worth it for the brothers on the front line in Hong Kong to fight from the 20th to 3:30 am on the 21st to finally reach an agreement. In this consensus, core and Chinese miners have obtained what they need under the same framework.

① No more splits <br/> If you were worried that Bitcoin would split into two coins, which would lead to a collapse in the price of the currency, now you can rest assured. Core agreed to hard fork to 2MB and incorporate it into the core framework. In exchange, Chinese miners also agreed to only run core. This is the biggest achievement of this consensus.

That is to say, even if there are disputes about whether to hard fork to 2MB ( hereinafter referred to as HF ), whether to deploy segregated witness ( hereinafter referred to as SW ), when to HF, when to SW, or whether to HF or SW first, they will only be carried out under the framework of the same core version, and there will no longer be the risk of version split. The two sides of the dispute have downgraded from a military struggle that may lead to the division of the country to a parliamentary struggle, and the danger has been greatly reduced.

This is also the fundamental reason why I called for the 92 consensus before. Whether in Bitcoin or in the Taiwan Strait, the 92 consensus can avoid the worst outcome - war and division.

② Guarantee of core developing HF code <br/> In order to ensure that core does indeed fulfill its promise to release a version containing HF, Chinese miners will deploy SW in exchange . In other words, if core does not fulfill its promise to release a version containing HF, or releases a version with unreasonable HF startup conditions (for example, requiring 95% of the computing power to agree to HF), then Chinese miners may refuse to deploy SW.

Please note that there is no promise here that SW will be officially effective if core releases the HF code - the SW soft fork requires 95% of the hashrate to take effect, which is not something the miners present can promise. It just means that after core releases the HF code, SW may enter the step of striving for 95% of the hashrate to take effect. Before SW officially takes effect, we will have enough time to carefully review its security.

③ HF time (July 2017)
This may be the biggest controversy of this consensus, and many people criticize that July 2017 is too late. But what I want to say is that I am a firm supporter of HF 2MB, as you can see from my previous articles, so please trust my interpretation. The original English text of this sentence is:

If there is strong community support, the hard-fork activation will likely happen around July 2017.

The exact translation is:

If there is broad support from the community, the hard fork could take effect around July 2017.

Different from the previous two clear times in April 2016 and by July 2016, this is a vague time around July 2017. Even a difference of three months is still a certain distance. This makes it difficult for the core to add hard time limits to the code, while the community has gained a lot of freedom.

If there is HF code, the block is full, and the mining pools have reached a consensus on the hash rate, then why not HF? The consensus only says that HF may be around July 2017, but does not prohibit HF before July 2017.

HF has a lot of testing work to do and a lot of peripheral software facilities to upgrade (many software may have 1MB hard-coded in the code). The preparation time for a HF is preferably 12 months, and at least 6 months. Therefore, July 2017 is also a reasonable time for HF.

In addition, if SW is officially implemented first, the indirect 1.6MB expansion effect should last for 6 months. If the block is full earlier, there will be no problem in implementing HF in April 2017 or even January.

④ HF vs SW
Of course, some people may worry that if core adds a mandatory July 2017 restriction (or any other behavior that hinders HF) to the hard fork code, wouldn’t that be bad? There is no need to worry too much. If core does this, there will definitely be mining pools that refuse to deploy SW, so SW will not be able to take effect. After the blocks are completely filled and blocked, both sides will be under increasing pressure until one side gives in, and the one who gives in is obviously core.

There are very good reasons for refusing to deploy SW - SW has made a lot of changes to the underlying Bitcoin code, and it takes a longer period of testing to prove its security, and this reason has nothing to do with the block. The reason for rejecting HF is nothing more than that HF without consensus is very dangerous, but with the block being blocked and the community increasingly reaching a consensus, the reason for rejecting HF is obviously becoming less and less tenable. Therefore, once HF challenges SW, HF will have a high probability of winning.

In addition, core is obviously unlikely to put itself in a position to anger and challenge the entire community again, only to have HF postponed for 6 months.

⑤ The problem of core’s dominance <br/> Others who are dissatisfied with the consensus may think that the consensus has not solved the problem, but has instead strengthened the core’s dictatorial behavior.

To be precise, the problem should be "Blockstream's dominance in the core". The core has made outstanding contributions to the development of Bitcoin, which we must thank. However, Blockstream hired some core developers (including two of the five cores) and exerted too much influence on Bitcoin development, which is also a problem we must solve.

But this cannot be solved by simply overthrowing Core and replacing it with Classic. Overthrowing Core may lead to the loss of excellent developers, and Classic may not be capable enough to take over the development of Bitcoin. Overthrowing Core does not essentially solve any problems. The two-party system seems suitable for governing, but there has never been a precedent that the two-party system is suitable for software development in the open source community.

At the haobtc party, Bitmain CEO Wu Jihan and haobtc CEO Wu Gang proposed that all companies should send people to participate in Bitcoin development, train their own core developers, contribute to Bitcoin development, and enhance their voice in the core, diluting Blockstream's influence. This is the ultimate solution to the problem. The open source community should not waste precious energy on the struggle between the two parties and mutual attacks.

⑥ Moving forward in unison
Therefore, this is indeed a great consensus, and it is the best result that can be achieved under the current conditions. I hope everyone can put aside the minor differences that have not yet been agreed upon, and work together to promote this expansion consensus. Don't waste your energy on attacking each other, but use it to solve the problems facing Bitcoin. Let us move forward together towards the stars and the sea of Bitcoin!

The above interpretation only represents personal opinions, and the interests involved are:
Founder of LTC1BTC.com, Bitcoin/Litecoin miner and holder

Finally, let us once again thank the contributors who worked hard and achieved this consensus with great means:
Pan Zhibiao
Manager
AntPool

Anatoly Legkodymov
CEO
A-XBT

Li Zhaojing
Bitcoin Association Hong Kong

Leonhard Weese
Bitcoin Association Hong Kong

Cory Fields
Bitcoin Core Contributor

Johnson Lau
Bitcoin Core Contributor

Luke Dashjr
Bitcoin Core Contributor

Matt Corallo
Bitcoin Core Contributor

Peter Todd
Bitcoin Core Contributor

Xie Kang
Bitcoin Roundtable

Phil Potter
Chief Strategy Officer
Bitfinex

Valery Vavilov
CEO
BitFury