The purpose of a Difficulty Adjustment Algorithm (DAA) is to dynamically adjust difficulty to changes in work (hashing) on the network in order to maintain a target block time. Natural variance occurs for many reasons and the DAA must strike a balance between stability and responsiveness. Difficulty that adjusts too quickly results in instability; difficulty that doesn’t adjust fast enough opens the door to flash mining. This compromise is more evident in small networks but as work (nethash) and communication channels (full nodes) increase the impact of a fixed size attack decreases. Said another way, the bigger the network, the more expensive an attack vector becomes.
The primary focus in Solo development following the move to 20 second block times has been on difficulty and network stability. Major Version 16 expanded the block window from 60 to 180, this normalized the window to the same target as was stable with 1 minute block times. Major Version 17 expanded the block window from 180 to 400. The following charts show the calculated next difficulty vs historical difficulty for both windows.
Shortly after the soft fork to v1.0.4.1 but days after the hard fork to Version 17 (block 350001) a negative timestamp attack was initiated on the Solo network. The chart below shows the distance between timestamps over time for blocks 350001 through 434000.
The code limits negative timestamps to -300 seconds, thus limiting the scope of the attack to some network instability and higher variability in block times. In the plot above, the attack and its effects on block time is visible starting shortly after block 361000.
The hard fork to Major Version 18 (Solo v1.0.4.4) addresses the issue where a negative timestamp would cause an artificial increase in difficulty. The DAA in Major Version 18 is the most recent version of LWMA1 with optional significant digit truncation. The following chart shows how the next difficulty would have adjusted historically if the algorithm was in place from block 350001.
The changes in difficulty were intentionally minimal, eliminating higher variance caused by the negative timestamp attack, but maintaining the 400 block window.
After performing simulations of various attacks, the code was tested in testnet with attacks ranging from extreme to probable. Tests performed addressed the following three questions:
- Are negative timestamps correctly accounted for?
- Can the network recover from a loss of 90% nethash?
- How profitable is a flash mining attack?
First the negative timestamp was tested for correct handling by the DAA, in conjunction the hashrate was cut by >90%. Difficulty was calculated correctly and did not increase due to the negative timestamp. As expected, block times increased significantly but the chain recovered with less than 10% of the previous hashrate.
The following is a summary of the data taken from the testnet testing.
The profitability of a flash mining attack is about 5% if the attacker roughly doubles the nethash. The visibility of this type of attack would be very apparent and the window is subject to change if this type of attack is detected. A smaller window would result in faster difficulty adjustments, thus reducing attack profitability. Stability will likely be maintained at a lower window with negative timestamps addressed.
Once testing was complete, Version 18 hard fork was scheduled for block 440001 - more than one-week advance notice. The hard fork was successful and difficulty variance has reduced since the hard fork. The current plan is to keep the difficulty algorithm in place as implemented in Version 18 and monitor for signs of flash mining attacks. If attacks are detected, the window may be shortened. As a part of future plans, an algorithm based on block time discounting is being developed.