Join and earn Bitcoin Cash for participation

Announcing the Grasberg DAA

76 1952 boost
Avatar for deadalnix
Written by
This user is who they claim to be.
We have manually verified this user via some other channel.
Proof
  126
3 months ago

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.

46
$ 17.06
$ 5.78 from @m4ktub
$ 2.00 from @Steve_Deplus
+ 22
Avatar for deadalnix
Written by
This user is who they claim to be.
We have manually verified this user via some other channel.
Proof
  126
3 months ago
Enjoyed this article?  Earn Bitcoin Cash by sharing it! Explain
...and you will also help the author collect more tips.

Comments

There are numerous severe problems with this article:

  • This article complains no concrete proposal has been made yet, but the Jonathan Toomim's ASERT proposal is way more concrete than this Grasberg thing, as evidenced by multiple implementations already being in development.
  • The relative formulation of ASERT is chosen despite the absolute formulation being superior on all aspects other than the temporary activation logic inconvenience for which Jonathan Toomim already proposed a simpler solution (fixing the block height).
  • A simple polynomial formula was replaced with a formula involving giant lookup tables. The giant lookup table makes the code impossible to read and humanly verify.
  • The lack of drift correction is suddenly considered unacceptable for ASERT but was never deemed problematic in all previous DAA changes.
  • There is no beginning of a description of how the drift correction is supposed to work, let alone any robustness analysis of this mechanism or any assessment of potentially undesired side effects.
  • Never in the history of bitcoin was there a drift correction mechanism. Despite the stated purpose to preserve the original emission policy, adding drift correction is itself a redefinition of the emission policy. It even literally contradicts the "moving average targeting an average number of blocks per hour" from the bitcoin whitepaper (p. 3) - it is no longer moving and the target is now something different.
  • Unlike the extensive ASERT proposal by Jonathan Toomim, zero simulation results or other quantitative analyses are presented in this article.
$ 14.55
3 months ago

Great work!

$ 0.56
3 months ago

I Found your article in homepage as boosted. very amazing and full of interesting information about The Grasberg DAA. Now I know that ASERT is a DAA proposal made by Mark Lundeberg which has very interesting properties and would be perfect for a new block chain. And what is the most I like is how you explained the drift correction.

$ 0.00
3 months ago

Time to fire Amaury. How long will this bullshit keep happening?

$ 0.00
3 months ago

Fire him? from his own software? It's open source. copy it and do it better. BCHN already started. If you think they are better people and less arrogant and socially hostile, then good for you. Good luck outcompeting ABC. This is the way to 'fire' him.

$ 0.05
3 months ago

Yeah. fire him and his ABC dictatorship.

I am sick of your ABC shilling

$ 0.00
3 months ago

blah.

$ 0.00
3 months ago

How can i be part of the Bitcoin Cash Community?

$ 0.00
3 months ago

Welcome, learn as much as you can, start helping others learn and join us at BCH Ignite https://discord.gg/Dvf79Xh

$ 0.00
3 months ago

great BCH

$ 0.00
3 months ago

Nice job

$ 0.00
User's avatar OG
3 months ago

Bitcoin ABC is therefore moving forward with the Grasberg DAA.

$ 0.00
3 months ago

All singn point to right.

$ 0.00
3 months ago

BCH ✌

$ 0.00
3 months ago

İm new in read.cash my cash account is very small😥 please help me

$ 0.00
3 months ago

From the looks of it, it is a great work!!! The other team has also something to propose but let's trust this work, it wouldn't do any good if the misunderstanding cant be undone. It would be be better if one should listen and follow. Nevertheless we expect it to be a success. Thanks for the immense talent in all this field.

$ 0.00
3 months ago

These is very good event though

$ 0.00
3 months ago

Aside from the fact that ABC is but one of many nodes supporting the BCH network, the statement "no concrete proposal has reached ABC at the time of this writing" is a complete falsehood.

For the first time in recent memory, there has been a node agnostic effort to work together to come to a new DAA solution. Everyone tried to put past differences aside in order to focus on the greater goal, the way a decentralized platform should operate. It was a beautiful thing!

But, now you just arbitrarily decide to do this and make it sound like no one else cared or was working on it? Why do you hate BCH so much? Why are you destined to make it fail? The rest of us simply cannot figure it out.

$ 11.01
User's avatar doc
3 months ago

So a concrete proposal has reached ABC at the time of this writing?

$ 0.00
3 months ago

[deleted]

$ 0.00
User's avatar doc
3 months ago

Your portrayal of the issue and especially your questions directed at Amaury are highly unconstructive. At least let the BCHAZ team come up with some sort of controversy that actually at least has the ambition to be a debatable argument.

$ 0.01
3 months ago

What do you mean by "concrete proposal"? Amaury is aware of Toomim's proposal here: https://read.cash/@jtoomim/bch-upgrade-proposal-use-asert-as-the-new-daa-1d875696 and accompanying C++ code here: https://gitlab.com/jtoomim/bitcoin-cash-node/-/commit/fd92035c2e8d16360fb3e314b626bf52f2a2be67#ee35cfc09ad35fa12b8d0a6280a950e4edde3d20_285_299 for quite some time. How much more concrete would qualify for you?

$ 0.60
3 months ago

My article included a link to an implementation:

https://read.cash/@jtoomim/bch-upgrade-proposal-use-asert-as-the-new-daa-1d875696

I also sent them a link to our implementation on July 17th:

https://gitlab.com/freetrader/bitcoin-cash-node/-/blob/daa/aserti3-wip/src/pow.cpp#L99

The only way ABC's objection makes sense here to me is if he's objecting to the fact that this code is not based on Bitcoin ABC, but instead on BCHN. Those two codebases are very similar. They could have copy-pasted code over easily. They chose not to.

$ 3.01
3 months ago

This is exactly what Amaury is saying as I understand it. The proposal was made on BCHN not on ABC. I don't understand why you did not chose to copy paste it or submit it to their software? you chose not to?

$ 0.00
3 months ago

We were still adding unit tests and other minor improvements at a rapid pace on the other repository. It didn't seem like fun trying to keep two repositories manually synced up all the time between two teams that didn't talk to each other. To avoid this overhead, I delayed by a few days. I encouraged ABC to look at the code where the development was happening. They did not.

They also did not check in with me since last week to let me know they were anxiously waiting and/or working on their own competing proposal. This proposal looks like the result of a couple weeks of work, though, so I suspect they started it right after I published my ASERT proposal paper.

Yesterday, after this Grasberg article was published, I took a couple of hours and copied the code over. It's here:

https://github.com/jtoomim/bitcoin-abc/tree/daa/aserti3-wip

$ 2.24
3 months ago

Hats off to you Jonathan.

$ 0.00
3 months ago

Because for a developer that step is trivial, both implementations are almost identical and Amaury can test, run and play around with BCHN just as easily as with ABC code. Also these discussions are usually done on pseudo-code level anyways, at least when proposing major changes like this drift adjustment.

Saying that you only review changes if they are made to your project is like saying you can't read a proposal article online because it was printed out and mailed to you (unneccessary hassle and clearly a pseudo argument)

$ 0.10
3 months ago

Kindly link to the submitted code for this concrete proposal. Thanks in advance.

$ 0.02
3 months ago

Choosing a reference point other than the genesis block is effectively equivalent to redefining the coin emission policy, which is a big NO.

I don't understand how you can argue this with a straight face. Satoshis DAA doesn't use the genesis block as reference either, but every 2016th block. Satoshis DAA is the definition of the coin emission policy, so we already threw that gem out with the EDA.

I think compensating past ineffecencies is a bad idea in general, especially when doing it as a surprise to everyone like you are now. There are real problems with drift correction, explained in this article by @freetrader: https://read.cash/@freetrader/on-drift-correction-39974f66

$ 0.00
3 months ago

Impressive and right on time to keep Bitcoin Cash growing with regular block times, restoring the emission schedule and more. Very nice!

$ 0.01
3 months ago

wow jesus christ you need to go away

$ 0.00
3 months ago

go away

$ 0.00
3 months ago

Very happy to see something being done about this long standing problem. Well done.

$ 0.00
3 months ago

drift correction mechanism

Why wasn't this discussed during the last DAA meeting?

Bitcoin ABC is therefore moving forward with the Grasberg DAA.

ABC style. Why not just propose this algorithm? A choice would have been made next monday.

$ 5.50
3 months ago

Great and informative article

$ 0.00
3 months ago

I figured this was going to happen. I do not know why. Perhaps because of ABC's history of rejecting proposals from other teams. Too bad.

$ 5.36
3 months ago

Are there any projects/coins you are interested in? I don't see non ABC node devs sticking around for long if Amaury's going to keep pulling this kind of move.

$ 2.00
3 months ago

I don't see non ABC node devs sticking around for long

We already saw most (I applaud the exceptions) of them stick around when the last DAA was pushed through Amaury-style and through the IFP debacle, too. What makes you think this time will be different.

$ 0.10
3 months ago

I don't like the attempt to "correct" the drift by targeting block intervals longer than 10 minutes.

$ 0.76
3 months ago

We’re talking about a max of 37 extra seconds here. I quite like this idea because BCH “will be possible to predict with a high degree of precision when a block is going to be mined, even many years in advance.”

I like this a lot actually!

$ 0.00
3 months ago

“will be possible to predict with a high degree of precision when a block is going to be mined

this is also true without drift correction. You just have to use a different starting point.

$ 0.10
3 months ago

What about the existing time-locked contracts on chain? the mecenas? payment channels?

What about smart contract development in the future?

In my view, this is essentially saying "we had a bad outcome the last 8 years, so lets have a bad outcome the next 8 years to fix it".

$ 0.11
3 months ago

I raised the point of Mecenas in yesterday's meeting and Mengerian provided a tweet link from Karol stating that Mecenas is using or can be made to use the MTP-based locks, and so that particular contract type is not problematic. Others might still be, but I don't know if anyone did a thorough review. It sure seems like the question wasn't really asked during the design phase of the drift correction strategy.

$ 1.50
User's avatar freetrader
This user is who they claim to be.
We have manually verified this user via some other channel.
Proof
3 months ago

Benevolent? Doubtful. Dictator? All signs point to yes.

$ 1.15
3 months ago

Good news. I don't understand all this negative reaction though. Folks, this is basically an implementation of the ASERT algorithm, plus a mechanism for correcting drift.

Correct me if I'm wrong, but don't we want to have a predictable emission schedule? Since so many talented people are already getting their hands dirty making a DAA change, the additional marginal cost of fixing drift compared to the benefit seems a no-brainer to me.

Now let's try to break this implementation in every way imaginable so we have something bullet proof for November!

$ 1.52
3 months ago

Correcting for historical drift means that in the future, we will be drifting by the same amount in the opposite direction until the two drifts cancel out. For every second we gained in the past, we will have to lose one second in the future.

BCH currently has a bit over 33,775 blocks (234 days) worth of drift due to the fact that Satoshi's DAA had an average block interval of about 568.29 seconds, plus another 4,653 blocks (33 days) of drift due to the fact that Amaury's 2017 EDA was attackable.

In order to correct for those two drifts, Amaury is proposing that we issue blocks slower than one per 600 seconds on average. If we spread our correction out over 10 years, then this correction will result in about 10 years worth of blocks at an average block interval of 637 seconds. This significantly deviates from the one-block-per-600-seconds emission schedule that most of us expect out of Bitcoin.

So we have a choice to make:

We can have 600 second blocks from here on out; or We can have >600 sec blocks for a few years to counterbalance the <600 second blocks of which we've already had 8 years.

My proposal did #1. Amaury's proposal does #2.

$ 8.58
3 months ago

will result in about 10 years worth of blocks at an average block interval of 637 seconds

In Amaury's article against shortening blocktime he states:

Bitcoin Cash has a script system that has time based features, such as locking coins for a certain amount of time before they are spendable. These features are essential for many smart contract systems, notably payment channels or recurring payment solutions such as Mecenas. These contracts do not have a source of time, and therefore use the blockchain itself as a clock. Changing the block time would therefore effectively change the speed at which time passes for all these contracts, breaking the system they are built upon. https://read.cash/@deadalnix/on-the-bitcoin-cash-block-time-88a6aa5e#why-is-it-harder-to-change-the-block-time-on-an-already-deployed-system

Is past Amaury arguing against present Amaury?

$ 2.12
3 months ago

This argument deserves MUCH more attention.

$ 0.01
3 months ago

how come it doesn't? Are people looking rather at other nonsensical arguments, that serves them more?

$ 0.00
3 months ago

Stop carrying all that water for Amaury.

$ 0.00
3 months ago

I do what I think is right. How about you accept the fact, that there are people who simply disagree?

$ 0.00
3 months ago

Yours sounds better.

$ 0.10
3 months ago

I mean... 37 seconds extra is not that long. I quite like the fact that BCH “will be possible to predict with a high degree of precision when a block is going to be mined, even many years in advance.”

That’s a great feature. I think it’s worth a couple of blocks with extra 37 seconds. Just my 2 cents!

$ 0.00
3 months ago

You already have that future without correcting for drift.

$ 0.20
3 months ago

It's 75 seconds, not 37. Check lines 123-127 of the diff.

$ 0.00
3 months ago

Thanks for running those numbers, and I believe that this is very well put. Essentially, it comes down to "we had a bad emission the last 8 years, lets have a bad emission the coming 8 years as well".

$ 0.10
3 months ago

It's 5.5 years of worse emission, actually. The BTC drift was about 560 seconds per block, whereas Grasberg will be 675 seconds per block.

$ 0.00
3 mo