This article was originally published in Chinese on my personal blog.
Because Bitcoin Unlimited contains no built-in mechanism for the activation of a hard fork, a hard fork to Bitcoin Unlimited consensus rules requires participating miner nodes to be in agreement with one another. If mining pools do not use the proper configuration, they open themselves up to the risk of a big block attack or a premature hard fork, both of which are very dangerous. With more and more mining pools taking an interest in Bitcoin Unlimited, I recommend that they follow the following steps in order to implement the hard fork.
The entire hard fork process should be broken down into three stages. The first stage is the miner signalling period. Once an entire difficulty period has passed with ≥75% hashrate signalling for Bitcoin Unlimited, we may proceed to the next step. The second stage is the preparation phase, which should last for two difficulty adjustment periods, giving the community time to upgrade their software to be in consensus with the impending hard fork. Should either of these two difficulty adjustment periods fail to meet the ≥75% signalling requirement, we revert back to the first stage. The third stage is the implementation stage, in which the hard fork actually occurs.
During the first of these stages, if miners have incorrect configurations or do not change Bitcoin Unlimited’s default settings, they open themselves to the possibility of big block attacks performed by malicious actors. If during this stage BU has minority hashrate and does not have the proper configuration, it may cause Bitcoin Unlimited miners to suffer significant damages. If the hashrate is split somewhat evenly between two clients, then Bitcoin faces the danger of splitting into two different coins. Improper configuration during the second stage may bring about a premature hard fork, causing confusion and disorder.
My recommendation is that during the first and second stages, mining pools change their Bitcoin Unlimited settings to EB1/AD6 so as to continue accepting 1MB blocks. “AD6” means that if a >1MB block is produced, the pool will wait until 6 blocks have been mined on top of that chain, as well as verifying that it is the chain with the most proof-of-work before switching over to that chain. This change is done by adding the following two lines into the Bitcoin config file:
excessiveblocksize=1000000
excessiveacceptdepth=6
If these settings are in place, an attacker must have 51% or more of the hashrate to successfully perform a big block attack. This should be sufficient to proceed safely. I do not advise AD being set too high, because in the third stage miners should simultaneously begin working on the chain with bigger blocks. AD6 ensures that even if a mining pool does not change their configuration in time, that they will still begin mining on the longer chain at the proper time and minimize potential losses.
Mining pools must also set their block version and signal the maximum block size they will produce. Bitcoin Unlimited’s default settings use Bitcoin Classic’s block version of 0x30000000, potentially creating confusion, so I recommend changing the block version to 0x20000000. The maximum block size (produced) setting should also be set to 1MB. To do this, add the following two lines to the Bitcoin config file:
blockversion=536870912
blockmaxsize=1000000
After entering the third stage, mining pools can update their settings to indicate the maximum block size that they are willing to accept, and the maximum block size they will produce. At this point the hard fork begins. I recommend first hard-forking to a 2MB max block size, as we know through testing that the network can already safely handle blocks of this size, minimizing the risk involved in a hard fork. To do this, add the following two lines to the Bitcoin config file:
excessiveblocksize=2000000
blockmaxsize=2000000
I believe that following this procedure and implementing these settings will minimize the risk involved with performing a hard fork.
