ASERT: Before and After

With the recent market fluctuations, I am seeing user enquiries about the performance of the new difficulty adjustment algorithm, ASERT, which replaced the previous one (referred to simply as DAA) on November 15, 2020.

I thought it would be good to open an analysis and discussion thread, to collect data and statistics that will give us all a picture of how the new algorithm has performed up to date.

With that in mind I went around the various sites that publish some insights on this, and I extracted some data from a node about block times for BCH blocks 504031…661647 (the “DAA era”) and 661648…675984 (the “ASERT era”, still ongoing but I sampled until 2021-02-23).

What I do not have, but what would be useful data, is the time from when a transaction was first seen until it was confirmed on the network. One of the anticipated benefits of ASERT would be to reduce the average time this takes.

2 Likes

Before we look deeper, I want to post some of the charts and figures out there.

This retrospective across BCH existence from 2017 until today, from bitinfocharts.com gives a nice overview. I’ve added bars to delineate the various algorithms in use (EDA in 2017, DAA from Nov’17 to Nov’20, and ASERT from Nov’20 until today).

EDA = Emergency Difficulty Adjustment, the original retargeting algorithm
DAA = the replacement for EDA, prone to periodic oscillation
ASERT = the replacement for DAA

User enquiries into “block time stability” are primarily driven by blocks that take a long time to mine, and exacerbated if their transactions are not included in the next block.
There are good explorer sites nowadays that include how long it took to to mine each block, even helpfully color-coding the instances where blocks take long.

(In the screenshot above, the final column indicates the “T.T.M” (Time to Mine), with blocks that took < 5 minutes in green, and blocks that took > 15 mins in red)

Understandably, users notice that blocks sometimes take an hour or longer, and wonder if the ASERT DAA is meeting its stated objectives.

I’ll include here the first 8 goals from Jonathan Toomim’s ASERT post (since the last 4/12 were about the new algorithm’s design properties and not about its performance):

  1. [ASERT] should be stable, and not prone to oscillations;
  2. It should keep [transaction] confirmation times low;
  3. It should keep incentives for miners to perform hashrate shenanigans low;
  4. It should keep incentives for miners to perform timestamp manipulation shenanigans low;
  5. It should keep incentives for miners to perform selfish mining shenanigans low;
  6. Because of #3, #4 and #5, honest mining strategies with steady hashrate should get near-optimal income;
  7. The chain should recover quickly after sudden changes in hashrate and/or exchange rate;
  8. The average block interval should be kept close to the target (e.g. 600 seconds);
1 Like

Basic descriptive statistics, compiled a while ago:

This is based on the CSV block data extracted from a node and uploaded in