*2489*

The Bitcoin Cash community has shown great interest in improving the DAA. While there is a lot of discussion around the DAA, no concrete proposal has reached ABC at the time of this writing, which does not leave us with sufficient time to review adequately, simulate and test, and get feedback addressed before the feature freeze on August 15th.

Bitcoin ABC is therefore moving forward with the Grasberg DAA.

The Grasberg DAA aims to solve 3 main problems existing right now on the Bitcoin Cash blockchain:

Ensure more consistent block production, which will translate into more reliable confirmation times for users, and will also reduce occurrences in which users run into per-block limits.

Ensure that steady miners get close to optimal profitability vs alternative mining strategies.

Ensure that the emission of coins follows a predictable schedule.

The source code for the Grasberg DAA is available for review.

## Design Choices

The Grasberg DAA is based on an ASERT core. ASERT is a DAA proposal made by Mark Lundeberg which has very interesting properties and would be perfect for a new blockchain, but it has to be modified slightly to fit Bitcoin Cash's requirements.

### Work-based

The original ASERT proposal assumes that work and target are inverse of each other. In practice this is not exactly true. While the difference is not big enough to make ASERT based on target unworkable, we should do what is correct as much as possible. Grasberg is therefore working on the work required to produce a block rather than the target.

### Fixed-point math

ASERT needs to compute an exponential. In order to make the DAA 100% predictable on all machines, the use of floating point needs to be banned. This lead to the implementation of a fixed point approximation of an exponential.

This approximation is computed via the use of lookup tables and a polynomial of order 2 to improve the result. This leads to a precision that exceeds the precision of the input which has a second granularity and is therefore deemed enough.

### Relative form

ASERT has two formulations, an absolute form, using a reference block, and a relative form using the two most recent blocks. While the absolute form has numerous advantages over the relative one, such as self-correcting imprecisions due to rounding, it does make the activation much more complex. The absolute form would certainly be preferable on a system that is built from scratch, but Bitcoin Cash has an history.

### Parameters

The chosen half-life is of 288 blocks, or 2 days, as suggested by Jonathan Toomim in his analysis of ASERT.

### Drift correction

Grasberg includes a drift correction mechanism. While ASERT does not drift very much on its own, Bitcoin Cash has experienced significant drift in the past. Choosing a reference point other than the genesis block is effectively equivalent to redefining the coin emission policy, which is a big NO.

The drift correction adjusts the targeted block time up or down slightly in order to catch up with the expected emission schedule. This adjustment is small and bounded in order to not disrupt the user experience. It is also purposefully defined to be tame so that its influence is bounded to larger time scales.

Some will find that this mechanism breaks the mathematical beauty of ASERT and they'd be correct. Unfortunately, ASERT in its absolute form using the genesis block as reference would jack up the difficulty so high due to pre-existing drift that it is a complete non-starter.

Once again, Bitcoin Cash is a chain with a history, not a new blockchain that we start from scratch. The upside of such a mechanism is that it ends up being more precise than ASERT at correcting drift. Once existing drift is absorbed, it will be possible to predict with a high degree of precision when a block is going to be mined, even many years in advance.

### Testing and simulations

Bitcoin ABC has already run simulations and real-world testing of this algorithm, but is inviting other parties to reproduce the results - hopefully - or not. We also want to encourage anyone with knowledge of C++ or DAA in general to review the source code of the Grasberg DAA.

There are numerous severe problems with this article: