[Bitcoin-ml] Alternative difficulty algorithm for Bitcoin Cash
erik.beijnoff at gmail.com
Mon Oct 9 22:19:35 UTC 2017
Reader beware, long mail below.
I have the last week been in discussions with most of the developers that seems to be engaged in addressing the difficulty algorithm weaknesses of Bitcoin Cash. This reply will:
1) List a number of assumptions about the situation
2) Evaluate the options that are available, from my perspective
3) Give my conclusion
4) List the next steps that I believe are expected from the central developers
- The current Bitcoin Cash difficulty algorithm is broken and corrective actions must be taken, irrespectively of if the EDA kicks in or not. The main culprit is the EDA in it’s current form, but other weaknesses exist as well. An example would be the oscillations caused by interaction between normal adjustment periods and EDA periods. In retrospect, the algorithm shouldn’t have been inherited from Bitcoin, but should instead have been a new one.
- This weakness is obvious to the market and acts as a constant downward pressure on the valuation; in the long term, it’s a threat to the survival of the currency. The conclusion that follows from this is that even if the EDA won’t be used again, the algorithm is still a weakness that must be remedied.
- There’s an instability in the algorithm that causes it to naturally tip over in either direction as soon as it isn’t in balance with BTC difficulty. To keep the system in balance, benevolent miners are forced to counter-mine against their own short-term self interest. They are also forced to do a tightrope walk when adjusting the difficulty through EDA. This requires both luck and miner engagement which they may not necessarily have either of.
- The current situation is not desirable by anyone. From my discussions I’ve understood that miners probably will welcome an updated algorithm. The only miners that will benefit from the situation long-term are those who might have hostile intentions.
- Unless an emergency situation appears, a rollout should happen after the November BTC 2x update. Preferably somewhere about two months from current date.
- Desired properties for an algorithm are robustness, simplicity and adaptability to shifting hash rates. Miners should be able to deploy hashing power in a fire-and-forget fashion.
2) Evaluation of options
Thanks to everyone involved for detailed explanations of the algorithms and also to everyone that have put proposals on the table. Any misinterpretations of the algorithms are completely on my side, do point them out if there are any.
Proposal by Tom Zander:
Makes the least changes to the current algorithm. The single addition that is made is an upwards counter balance for the EDA, which is intended to quickly adjust difficulty upwards if “too much” hashing power is applied.
- Simplicity, least interference with current mechanics
- Keeps the two separate adjustment periods. They have shown to cause oscillations when the system is thrown off balance.
- The coarseness and flaws of both the old Bitcoin algorithm and the EDA remains.
Proposal by deadalnix:
For each block there are two different difficulty adjustment suggestions. One is calculated over a 2016 block window and one over a shorter window based on block timestamps going back 130 minutes. Exact number of blocks depends on how the timestamps are spread over the blocks. If the two suggestions differ in difficulty by more than 25%, the fast window suggestion is used. Due to that fast window adjustment is based on time rather than block count, the difficulty adjustment is symmetrical over time but asymmetrical over blocks; adjustments can happen faster downwards than upwards.
- Based on the algorithm of Zcach, therefore somewhat field tested. Zcach does not have two windows though.
- Seems more complicated than necessary
- Possibly inherits some problematic properties of Bitcoin’s original algorithm
- Two disconnected difficulty adjustments windows. Is it useful?
- Asymmetrical difficulty adjustment when looking at block count. Opens to oscillations or time warp attacks? The tests of Kyuuchipan indicates instability under certain conditions
Proposal by kyuupichan:
For each block, a window of the previous 6 blocks is used to calculate a small adjustment depending on the timestamps of those blocks. A complementary 2016 block window intended for emergency use only exists to prevent long range time warp attacks. It can only adjust upwards. Both adjustments build on top of each other.
- One unified algorithm, not separate adjustments
- Good simulation suite that seems to indicate robustness and adaptability
- Is a window as short as 6 blocks suitable?
- Can the one sided 2016 block window upwards adjustment be abused?
- No prior live testing of the algorithm
I am strongly in favour of replacing the current algorithm in full since it is proven to have big flaws. If a network wide upgrade is required anyway, I see no benefit in just patching the existing algorithm . Especially if it instead can be replaced with a modern, better working one. The higher risk of changing to a new algorithm is countered by the drawbacks that already exist with the current one, and by patching we are keeping the flaws of the old one. Thereby risking a need to change the algorithm once more further down the line. Which could be very costly.
To me the clear choice is kyuupichan’s proposal. This is due to simplicity, addressing the need for an EDA-like adjustment speed and what seems like robustness shown by the tests that he has provided. The main drawback is that it hasn’t proven itself in the wild yet. I also think that the short 6 block window should be discussed before it is settled on.
Kyuupichan’s proposal is therefore the one I will promote going forward.
4) Next steps
I intend to reach out to everyone that I see as central for arriving at a common suggestion.Those are:
- Tom Zander
- Peter Rizun
If you think someone is missing from this list, do please add them.
Once I have gotten the chance to get feedback from everyone, I’ll try to coordinate approaching the miners with a common suggestion, together with a time plan for implementation. I’m aware that most of you are already in contact with them, but I think it would be healthy if a common front could be presented. If any exists.
More information about the bitcoin-ml