LWMA Failures

[zawy12]

Here "failure" means a delay was over 40 minutes in a T=120 coin. I have not seen a 3 hour delay in an LWMA. Before LWMA, "failure" meant a 3 hour to 3 day delay.

The root cause of these failures is that a large miner (>5x the baseline hashrate) is willing to start mining at a noticeably higher D than dedicated miners are willing to mine at and pushes it up over 30% higher, and then stop. Constant miners leaving when it gets high adds to the oscillations. There does not appear to be any solution. I faster algorithm would reduce the number of blocks he mines from 15 to 20 to about 6, but they can accept the shorter mining time and the faster algorithm can make the delays longer.

I've seen a few days of LWMA failure in 3 coins: Niobio, Iridium, and BTC Candy. These failures revealed LWMA was clearly not rising fast enough. The D-LWMA fixes it's inability to rise fast enough when a > 5x miner jumps on. I have not found a way to help it rise faster when 1x to 4x miners jump on without causing too much instability. Being slow to rise has a purpose: most solvetimes are less than average solvetime. There needs to be some skepticism before rising. This is why LWMA rises the fastest for a given amount of stability. It seems to clearly need to rise faster sometimes, but sometimes that "clarity" is really an illusion: avg of 10 solvetimes < 1/2 the target and avg 5 solvetimes < 1/5 the target each occur on accident more than once per day in T=120 coins.

The LWMA and D-LWMA are awesome at dropping to the correct difficulty in only 1 or 2 blocks. But there is a situation where there is no fix to stopping the long delay. The 3 failures appear to be caused by a 30x miner (30x the "dedicated" miners' hashrate) wanting to begin mining whenever D is < 1/30 the correct difficulty for that miner, and he mines until it rises to 1/15 of the correct D. So when he leaves, there is an average 15x delay which is a 30x delay about 1/4 of the time.

This shows the worst example of LWMA failure that occurred one day in Bitcoin Candy.

Masari data shows a milder version of this:

The bigger peaks average 10xT delays for a single block before the big drops, so this does not qualify as a "failure" as I defined it, but it looks like a situation that can be improved. If the "blocks stolen" does not improve, and if there is a better solution out there, then it is a failure.

Worse, a large percent of your dedicated miners may leave when D rises only 25%. This appeared to be happening in Iridium which had 1 hour delays every 20 blocks where most of the 20 blocks were taken 30x faster by a 30x miner. So the miner had to suffer only a 25% rise in D instead of a 100% rise described in the previous paragraph.

[lukepighetti]

Hello. I am looking for a simple LWMA n=30 implementation that is compatible with bitcoin 0.15.99 source. I have tried emailing you and am also available via Discord in the Pigeoncoin server. Would love to discuss this with you before implementing it from scratch.

[zawy12]

I found your email in my spam folder and sent the discord invite. N=30 varies too much. It will attract on-off mining. BTG has good code for BTC coins

[zawy12]

As the POW mining situation changes, 3 more coins have seen unfriendly oscillations in LWMA caused by on-off mining. Mainly Masari who previously had the best long-term success with LWMA. Wownero and Intense have also been seeing some oscillations. BTC had by far the worst problem, and they came up with what is so far working great. There is only 6 days of data.

Here it is before and after. First on a big scale to show how big the peaks were, then on my normal scale so that it does not appear overly smooth compared to other LWMAs,

Big scale:

Normal Scaling:

They lowered they N to 45 and used the following logic::

if ( avg_10_ST < T/4 & next_D < 2*avg_10_D )
   { next_D = 2*avg_10_D; }

else if (avg_10_ST < T/2 & next_D < 1.5*avg_10_D )
    { next_D = 1.5*avg_10_D; }

if ( next_D < 0.77*prev_D )
    { next_D = 0.77*prev_D; }

I will investigate trying to optimize this because I don't think it will help Masari's nearly-awful oscillations and the less-bad oscillation situations. Time will show if on-off miners find a different oscillation pattern to get more out of the above.

Here is a link to their code which is done on targets instead of difficulty. https://github.com/bitcoincandyofficial/bitcoincandy/blob/e92e12c1b5fb9df46e2cd2f29403c7bd44e7ec35/src/pow.cpp#L113