Note: This article has been kindly translated into Chinese
It has been almost a month since Bitcoin successfully split into two descendants: Bitcoin and Bitcoin Cash. The hard fork that marked the birth of Bitcoin Cash created some new rules for this offspring currency, most notably the removal of the 1MB block size limit that was hobbling Bitcoin’s growth. But there were also other important changes that were implemented to allow Bitcoin Cash to split cleanly and coexist with Bitcoin.
One of these additional changes is known as the Emergency Difficulty Adjustment (EDA). The EDA was implemented as a relatively safe and minimal change to allow Bitcoin Cash to survive by adjusting difficulty downward if it has only a small proportion of the hash rate. At the time it was implemented, this decision made sense. As the post-split situation was not predictable in advance, it was sensible to implement a minimal solution that allowed Bitcoin Cash to survive if it had only a small proportion of hash rate support, but also left open the possibility of leaving the difficulty algorithm unchanged if Bitcoin Cash garnered majority support quickly.
Now that the split has happened, we have information on the actual situation in which Bitcoin Cash exists. We now know that Bitcoin Cash is in a minority hash rate position, and we have the benefit of experience showing us that the EDA mechanism, while allowing Bitcoin Cash to survive, is not optimal since it results in hash rate oscillations between Bitcoin and Bitcoin Cash.
A Difficult Problem
The problem of hash rate instability has been well known for many years in the altcoin community. Multipool mining, where miners could quickly switch between mining coins with compatible Proof of Work algorithms, led to hash rate oscillation and instability. This rapidly switching hash power would often lead to unpredictable confirmation times, and long periods with very slow blocks. There were also more serious problems when coins had widely divergent market values, which could leave the smaller coin vulnerable to miners gaming of the difficulty algorithm, and manipulating timestamps.
In order to deal with these problems, altcoins have come up with various innovative difficulty algorithms such as “Kimoto Gravity Well” [1], “MIDAS” [2], “Dark Gravity Wave” (Dash) [3], and “digishield” (DigiByte, Zcash) [4, 5, 6]. These difficulty algorithms make various tradeoffs between different goals, such as: responsiveness to sudden changes in hash rate, protection against timestamp manipulation, and the accurate targeting of block production (and thus inflation) schedule. The most thorough analysis of these tradeoffs I am aware of was conducted by zawy12 working on the Cryptonote difficulty adjustment algorithm [7].
No matter what difficulty targeting algorithm is used, there will always be some theoretical instability when two coins share the same proof-or-work. This is because for any small difference in profitability between the two coins (say a 1% difference for example), there will be an incentive for 100% of the miners to switch to mining the more profitable coin. In practice, however, it has been observed that when difficulty comes close enough to matching market price, the hash rates will stabilize.
For example, during the Ethereum split into Ethereum and Ethereum Classic, we observed that the quicker and smoother difficulty targeting algorithm led to a stable situation where each coin stabilized to a hash rate proportional to its market value. This suggests that a similarly smooth and responsive difficulty algorithm for Bitcoin Cash would stabilize its hash rate relative to Bitcoin.
A Path Forward for Bitcoin Cash
There has been discussion percolating in the Bitcoin Cash community about how to address this hash rate oscillation issue. Recently, a well developed analysis and proposal has come from Bitcoin ABC developer Amaury Séchet (deadalnix), in a recent post the bitcoin-ml mailing list [8]. His work builds on the analysis of zawy12 [7], and includes simulation to validate its performance under various scenarios. It is a robust solution that would serve Bitcoin Cash well for the long term.
If this new difficulty targeting algorithm gets adopted, Bitcoin Cash and Bitcoin could coexist harmoniously, while sharing the same Proof of Work. This would allow each coin to pursue the technical and economic improvements that they feel are best for their community, independently from each other and with no mutual hindrance.
This improved difficulty algorithm requires a hard fork, and thus would take some time (likely months) to deploy in a careful and responsible way. In the meantime, the Emergency Difficulty Adjustment mechanism will continue to permit the survival and viability of Bitcoin Cash.
Update [2017–09–29] Sechet has published an implementation of his difficulty algorithm at: https://reviews.bitcoinabc.org/D571
[1] https://cryptofrenzy.wordpress.com/2014/02/09/multipools-vs-gravity-well/
[3] https://www.dash.org/dark-gravity-wave/
[4] https://www.reddit.com/r/Digibyte/comments/213t7b/what_is_digishield_how_it_works_to_retarget/
[5] https://forum.z.cash/t/final-zcash-mining-specifications/355
[6] https://github.com/zcash/zcash/issues/147
[8] https://lists.linuxfoundation.org/pipermail/bitcoin-ml/2017-August/000136.html
