[Bitcoin-ml] Alternative difficulty algorithm for Bitcoin Cash

[freetrader]

Tom Zander wrote about proposals for a faster diff algorithm:

> This goal was ignoring the bigger picture of stability of mining earnings.
> In short, it [much faster diff adjust] removes the certainty of a minimum amount of profit per energy consumption a miner can expect for a 2 week period. We need to balance those concerns out, something that the original algorithm does very well.

Please allow me to question this goal (of the algorithm - not of miners).

Stability of miner earnings, in terms of a "certainty of a minimum of profit" is *not* guaranteed by the difficulty algorithm - how can it be?
If anything, large negative market moves ("crash") can be much more sudden, and have reached > 50% drops within three days [1]. A 2 week cycle seems like faint protection against such a situation.

Freezing the difficulty for 2016 blocks does not translate to a fixed time period of stable earnings.
If hashrate moves in, blocks come faster and the individual miner earns less proportionally while the next difficulty adjustment comes quicker.

We can predict what happens to hashrate, and consequently to system performance with the legacy algorithm, if there were to be a serious price crash. Under those circumstances, the 2 week interval could become an albatross around a miner's neck.
Price effectively buys security, and if the price drops, the security of the system eventually follows suit, lowering the difficulty. More miners can stay in business by hashing at lower cost, and the main goal of stable average block times is achieved. Swift adjustment protects the smaller miners who have comparatively fewer economies of scale and reserves to absorb price shocks.

Inversely, it offers stable performance in the face of sudden price rises and consequent increases in hashrate. As we see with the EDA, very fast block times are currently perceived by users of the system as not really useful and even unfairly benefitting miners. The accepted ten-minute block interval is regarded by users as a high good that stands for stability of the system and adherence to the emission schedule.

Nowadays miners work with cryptocurrencies that have faster retargeting (Litecoin, Ethereum), and are already skilled at managing them. Agility becomes a deciding factor when there is free competition for hashpower. Sometimes the argument is made that the two week interval protects the incumbent chain against minority hardforks. I maintain that a minority challenger would simply hard fork to a quicker retargeting to render such advantage moot. This was half applied for some asymmetric advantage with the EDA, which is already evaluated on every block.
I do not see an advantage in delaying a move to a fully symmetric per-block algorithm in the next hard fork. To me, that seems like introducing an Achilles heel that will be taken advantage of by a subsequent fork. I think the market success of a fork should depend as much as possible on the actual important functional changes they bring, and less on making little tactical adjustments to a retargeting algorithm.
That's my outlook as we enter the phase of further analysis of the proposals.

Regards,
freetrader

[1] https://www.forbes.com/sites/timothylee/2013/04/11/an-illustrated-history-of-bitcoin-crashes

P.S. I've asked this a while back on other forums, but never got a really satisfactory answer: Has anyone seen a firm rationale given by Satoshi or someone else informed by him on the choice of the 2-week interval?
I assume it is not entirely an arbitrary design choice, but based on the assumptions of one month as common billing period for utilities, and the choice of maximum adjustment factor (x4 up or down / 2 weeks, i.e. max halving/doubling per week) which constrains the fluctuations that the algorithm is able to track. I'd be interested to hear whether anyone can put the resulting 2-week interval choice on a decent theoretical footing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20171003/dfa6d6ac/attachment-0003.html>