Bitcoin cash new DAA performance

[zawy12]

This isn't an issue that needs resolving. I just didn't know of a better place to put this.

I'll post an updates in this thread.

It looks like the DAA will work well. After an initial problem due to starting at a level much lower than optimal (not shown because it was < 144 blocks), it overshot the difficulty and caused a period of only 8 blocks in 6 hours (shown as the peak on left). Then it went through a period of 2.5x more blocks than target for 4 hours (period where blue time line is below the green line). Now due to a lowering in price, it is overshooting the difficulty a little bit.

It takes it about 50 blocks before it responded to an obvious need to increase difficulty. This caused it to overshoot. Hopefully the severity in the first cycle will not be seen again, unless price changes abruptly.
There are 3 elements that will cause oscillations in the future: price changes combined with the large N that causes price to be about 70 blocks ahead of difficulty, and miners having the option to go back to a larger coin (BTC). These three things combined will cause oscillations that are beyond the statistical expectation. A 4th thing is not a root cause but it greatly amplifies the effect: miners non-linearly jumping on and off the coin. By that I mean a 30% disconnect between price and difficulty (i.e. difficulty is 30% too high or too low as a result of being too slow from large N=144) causes a 300% change in hashpower.

I'm surprised to see how much miners jump on when it goes 25% below their target difficulty. Hashpower increases 200% (3x more mining). It seems to take an overshoot of 40% to go to 1/3 the correct difficulty.

The target difficulty line is 0.80 x (BTC difficulty) / (BCH price in BTC). There were 2 times where solvetime appeared correct, which is how I came up with the 0.80 factor. So it appears miners are "20% less enthusiastic" about BCH compared to BTC, for a given price.

[zawy12]

I spoke too soon. This second oscillation is making me think the DAA is a "near disaster" instead of "OK".

Here's Bitcoin Cash's N=144 compared to Karbowanek (small "Ukranian Monero") coin's simple moving average N=17. They do not have any limits on the rise or fall or timestamp error protection (other than the default Monero MTP and node peer time limits). They chose this after having to fork from Cryptonote's default N=300 and seeing a post of mine saying "use simple N=17" in October 2016.

Both charts are scaled to "1" for the average difficulty and target solvetime.

I've been arguing against N>30 for over a year, and all 4 of the people working on Bitcoin Cash were citing my work as a starting point, but still my main message was ignored. I recently acquiesced to N=50 due to people not being open to N=30.

Now that 84 blocks were found in 4 hours and 144 should be found in 24, it should take about 24-4 = 20 hours to find 144-84 = the next 60 blocks, which is about 3 blocks per hour instead of 6. But since ~ 66% of miners are going to suddenly leave after difficulty rises 30% above where it should be, the delays should be close to taking 4 hours to find 6 blocks sometime in the next 80 blocks [update: it took 4 hours to get 7 blocks 35 blocks after this post]. Such delays have not been seen in Karbowanek coin since it changed to N=17, about 130,000 blocks ago. Out of 8000 blocks, Karbowanek touched upon 20% of the target solvetime only twice for about 5 blocks. Bitcoin Cash has already done this for 60 blocks in one 144 cycle (naively speaking, that's 10x worse and 50x more often).

It looks like it there could be 4 hour periods to get 6 confirmations every day or so.

[zawy12]

I spoke too soon again. The last 3.6 days (right half of the chart) have been perfectly fine in delays, in line with other coins I'm checking. The first 3 days seem to have been an oscillation caused by start up that was being extended by "unlucky" price changes.

[deadalnix]

You got to consider that historical data at first were based on the previous EDA. In addition, we saw of a lot of fairly important price changes lately. It looks like things are becoming more stable over time.

It's useful to have the data you present, it'll allow us to see if this needs improvement or is good enough, and if improvements are needed, to quatify them.

[zawy12]

My charts start 144 blocks after EDA. Yes, definitely, the leftover from that caused the first oscillation. If the price had not conspired to keep it going, it would not have gone through the 3 cycles. It'll probably come back now and again, but it should be fine. Even so, you should employ the best available if there's a hard fork in the future. For good karma if for nothing else. In the following, avg of 11 solvetimes above 2.5 are not good. The first three are in the startup period. Ideal is to stay below 2 most of the time.

[zawy12]

For comparison here are other coins.

[zawy12]

From "OK" to "near disaster" to "best I've seen". After the first 5 days of oscillations, the new DAA has been doing great, if delays are the only concern. It's causing me to to re-evaluate my long-term desire to promote fast-responding difficulty algorithms. If the price isn't swinging more wildly than it has been the past 8 days, then N=144 looks like a great choice. A good way to measure delays is to do a rolling average of 11 solvetimes and count block averages that are more than 2x the target solvetime 10 minutes. On this measure, the past 8 days were 0.70% of blocks with delays. N=63 has about 1.3% and N=17 has 3.5%. A problem with the 0.7% of N=144 is that the delays are more all bunched together. Also, in testing and in the above, if price changes much, or if miners come on and off for other reasons, N=144 is much worse than lower N when it comes to these delays. So it still needs to prove itself more with BCH and it may still be risky for small coins.

The 3 peaks at the beginning are the 2nd to 5th days since the new algo began. The 0.70% begins at block 504804.

To analyze what happened in the first 5 days: Difficulty started way low, which caused an overshoot (just before the chart) in both difficulty and solvetimes as miners jump ship. If price were stable and if miners were not of the same mind and jumping off all at once with a 25% change in price/difficulty ratio, there wold have been only 1 peak instead of 4. The overshoot (combined with the 'miner threshold effect" of jumping on/off ship) caused a subsequent undershoot that was made worse by a decrease in coin price. This led to another overshoot that was exacerbated by a price increase (see chart lines). This led to an undershoot that was again exacerbated by a price increase. This led to an undershoot with a stable price. This led to another overshoot that was helped by a price increase. But as the price did not again conspire against the difficulty, things stabilized after that. With a mere price change that is not combining with a previous overshoot or undershoot, there is not a bad oscillation. It will take to price changes of the right timing to cause another bad oscillation.

[deadalnix]

Thanks for all the data. It seems like it's not an issue and thing just needed some time to settle down.

[zawy12]

It's kind of below par. I forgot to do an update. Here's a newer look at it comparing it to 5 other coins:
zawy12/difficulty-algorithms#6

The new algorithm by I think Neil that is being tested is really good and easier to implement than the others. It's not the fastest response, but it's a lot better than the current DAA:
kyuupichan/difficulty#30

[zawy12]

It turns out it is just as fast as the others and it allows negative solvetimes (which are really needed) and integer math on the target.

zawy12/difficulty-algorithms#17

I am recommending an N=20 for coins with T=600 seconds. Its N is like an SMA with 2x the N, so N=20 is like WT-144 with N=40. I've done a lot of work trying to determine the best N. At first BCH did a lot better than I expected, but it's still having some problems. They are investigating N=100 but that's like WT with N=200. They originally thought they were making it an N=72. So, assuming my recommendation of N=20 is not followed, and assuming you see N=144 is too slow (although SMA is slow to respond anyway), you will probably like to use N=50 as a compromise., which is like a really good SMA with N=100.