[BRIP-3] Difficulty adjustment algorithm

[tazman97-BR]

Concern

In the early days of a new protocol the hash rate may vary significantly. Bitcoin’s difficulty adjustment algorithm that adjusts the difficulty every 2016 blocks does not react fast enough to potential major changes in the hash rate. Significant changes in the hash rate may lead to long periods of expedited mining when additional hash power is injected to the system or very slow block creation when hash power is taken out.

Moreover, bad acting miners may exploit their available hash power to receive more block rewards than their actual hash power. An example for a hash attack may be increasing the hash power for periodic time windows.

Solution

Difficulty adjustment algorithms such as Digishield, EMA or LWMA can provide faster response and higher stability.

[tazman97-BR]

See @zawy12 work on LWMA difficulty algorithm

[ianduoteli]

For this BRIP to be considered for integration, please submit proposed implementation via a pull request to https://github.com/bitcoinroyale/bitcoinroyale

[ianduoteli]

Changing Bitcoin's original 2 week difficulty adjustment period is obviously a must for any young fork. It's common practice to adjust difficulty per block and can be seen in ZCash, Bitcoin Gold, Bitcon Cash, etc. I've renamed this to a BRIP since this topic is not discussed at all in the white paper.

[ianduoteli]

I created several simulations to compare the various algorithms: https://github.com/ianduoteli/pow-difficulty-simulations

My conclusion is that LWMA is indeed the ideal choice. I would recommend though to change the window to 20 in the early days of the coin (and increase int the future to 45). Also, I recommend to remove the 6*T limit to prevent large drops in difficulty from long solvetimes in the beginning.

[zawy12]

@ianduoteli Even as low as 45 is risky because it accidentally goes low 20 % every day and thereby attracts on-off mining. The 6xT is there for a similar reason. Without it, coins experiencing sizable on-off mining do noticeably worse. But without it other coins do a little better. So that one was kind of a hard decision. Those variables are the result of say a month of work, hundreds of simulations, and watching results on dozens of coins over months.

[zawy12]

Just to make sure, do not use the MTP like Zcash as the most recent solvetimes. LWMA's speed at N=45 is enough that Zcash's 6-block delay could throw it into constant large oscillations.

[ianduoteli]

@zawy12 Thanks for the response! I'm confident in your LWMA param observations for a more mature coin that has substantial hash power. What do you think about a new coin that is just starting?

In the beginning there is very little organic hash power and the coin is very susceptible to attack by renting spikes of hash power. Most of your simulations are for x10 attacks, but in the beginning I believe x100 or even x1000 attacks are possible and not extremely expensive. I was thinking about keeping the lower parameters for a few months and then proposing a fork to your values.

[zawy12]

There's been only 1 coin that was unable to survive, bitcoin candy. There was some big miner who was pretty much the only one interested in mining and he would send it high then leave. Actually maybe they did not get stuck, but the delays were huge and interminable. 100x could result in 100x delays for 1 block which is unavoidable unless you do the exotic measure of changing difficulty during the block, based on the timestamp in the same block header. See my TSA article. I would just use it as is with N=45.