Written by Jiang Zhuoer, translated by me
[The original statement Deducted]
This statement is a consensus of great significance by Chinese miners and Core devs, worthy of the effort to negotiate/debate till 3:30am. Within the same framework, Core and Chinese miners have both achieved fruitful results.
- 1 No more splitting
If you've worried bitcoin will end up with two different coins, leading to a market crash - you should rest assured. The major result of the meeting is: Core agreed to add 2MB hard fork in code, and in exchange, Chinese miners agree to continue to run core. There will be only one framework where we determine when and how to HF/SW. The risk of splitting is thus reduced greatly.
- 2 Core's promise of working on hard fork
To ensure core will release a version containing hard fork code, Chinese Miners will agree to deploy SW. In other words, if core refuses to deliver a HF version, or the software is with inadequate activation prerequisites (such as HF triggered only with 95% or more hashrate agree), our miners can refuse SW.
- 3 HF time (July 2017)
This point by far has given rise to most controversy. Many argue that July 2017 is too late. However, we should note that in statement "...activation will likely happen around July 2017...." meaning that the HF time will be near/close to, but might not be exactly in July 2017. Therefore if before July we have the HF code, already full blocks and almost universal agreement by hashrate, there's no reason not to activate HF before July.
Besides, an HF involves lots of testing and upgrades, which would require 12 months normally, 6 months at least. So July 2017 was not a bad choice. On the other hand, if we have SW in effect, the 1.6 MB size should still buy us some months of time before the HF.
- 4 HF vs SW
Some might be nervous about this: what would happen if core intentionally added too much restrictions in HF code? If core did so, our pools can also refuse SW activation. Once blocks are entirely congested, both sides will take great pressure, until one side gives up.
The opinions against SW is the considerable modification on bitcoin code base, that requires a long time to test its safety. This is irrelevant to the jammed blocks. However, to reject a HF is because of the risk of potential contentions. Given that blocks are congested, the community would be unify the voice to ask for the HF. Therefore the contentious fork is no longer a problem. In this scenario, HF is more likely to win over SW.
- 5 Dominance of Core
Many against the consensus worries about that core will be the only dominant dev team in BTC world. We should indeed thank core team for their unparalleled contribution. But potential cooperation interest should also be considered.
Yet simply overthrowing Core and coronating classic will not solve this problem. In previous meetings, many companies have suggested to train and support other coders to work for core software, and contribute to a more diversified team. We think this would ultimately help the situation.
- 6 Move ahead united
The result of the meeting is the best we could achieve at the moment. Hope we all let go the minor difference in our minds and promote the consensus. Please waste no more effort on attacking each other. Instead we should focus on more pressing problems. Together, our conquest is the sea of stars!
*modified as suggested by the author
Submitted February 23, 2016 at 10:56PM by nextblast http://bit.ly/1WGttue
No comments :
Post a Comment