Announcing the Grasberg DAA

76 2534

Written by

This user is who they claim to be.
We have manually verified this user via some other channel.
Proof

Bitcoin Cash founder

3 years 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.

$ 17.06

$ 5.78 from @m4ktub

$ 2.25 from Anonymous user(s)

$ 2.00 from @Nicknameul

+ 22 more contributions

$ 5.78 from @m4ktub

$ 2.25 from Anonymous user(s)

$ 2.00 from @Nicknameul

$ 2.00 from @Steve_Deplus

$ 1.00 from @Cain

$ 1.00 from @Marco

$ 1.00 from @Mengerian

$ 0.51 from @georgedonnelly

$ 0.26 from @unitedstatian

$ 0.20 from @Fidel

+ 15 more contributions

Written by

deadalnix

This user is who they claim to be.
We have manually verified this user via some other channel.
Proof

Bitcoin Cash founder

3 years 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

BigBlockIfTrue

3 years 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

molecular

3 years ago

For reference, the concrete proposal that apparently never reached ABC was published three weeks ago:

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

and the code is here:

https://github.com/jtoomim/bitcoin-abc/commit/83de74761631e509cba3fd58455b9f094e219a8c

$ 30.12

jtoomim

3 years ago

Bonjour Amaury,

Je suis un grand soutien de votre travail chez Bitcoin ABC, et serais heureux de vous rencontrer s'il advenait que vous vous rendiez a Lyon. N'hésitez pas à me contacter et serais plus qu'enchanté d'échanger avec vous.

Vous avez tout mon soutien dans votre noble combat contre les monnaies étatiques.

Un Français qui vous veux du bien.

Cordialement

$ 0.00

FrenchLegalAspect

3 years ago

no concrete proposal has reached ABC at the time of this writing

False: the concrete proposal (with code) of an integer-approximation ASERT by Jonathan Toomim reached ABC (and everyone else) and was discussed in the last DAA meeting.

While the absolute form has numerous advantages over the relative one, [...], it does make the activation much more complex.

False: activation is practically trivial to implement either way. MTP-based activation for (absolutely-scheduled) ASERT has already been implemented. It's an extremely simple function which can be removed a short while after the fork when the exact reference block height, target and timestamp can be hardcoded into the DAA. This is the same in either case.

This [drift correction] adjustment is small and bounded in order to not disrupt the user experience.

No evidence to support this yet. In fact...

Bitcoin ABC has already run simulations and real-world testing of this algorithm, but is inviting other parties to reproduce the results

These results seem not to have been published so far. The first question other parties would ask is : where to find these results? And hopefully they are not only results, but methodology that allows reproduction, unlike the case for the previous DAA selection.

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.

By this logic, no-one else has "sufficient time to review adequately, simulate and test" this algorithm which has been introduced even later and in all likelihood reviewed, simulated and tested much less than the existing ASERT implementation by Jonathan Toomim.

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.

"high degree of precision" - remains to be quantified.

There is zero evidence so far that it would exceed the predictive precision of an absolutely scheduled ASERT based on a very-recent (near the upgrade fork) reference block.

Once existing drift is absorbed, it will be possible to predict [..]

And until that drift has been absorbed? No mention of how long that's going to take in this article.

Bitcoin ABC is therefore moving forward with the Grasberg DAA.

Not sure what you mean.

Other nodes have been invited to a BCH developer meeting to discuss DAA work.

It sounds like ABC is trying to pre-empt any decisions of that meeting.

This is very reminiscent of past events.

$ 26.93

freetrader

This user is who they claim to be.
We have manually verified this user via some other channel.
Proof

3 years ago

No true

$ 0.00

ChrisJohnson

3 years 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

Marco

3 years 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

jtoomim

3 years 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

Nicknameul

3 years ago

You already have that future without correcting for drift.

$ 0.20

JonathanSilverblood

3 years ago

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

$ 0.00

jtoomim

3 years 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

CapitalFlight

3 years ago

This argument deserves MUCH more attention.

$ 0.01

JonathanSilverblood

3 years ago

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

$ 0.00

Koush

3 years ago

Stop carrying all that water for Amaury.

$ 0.00

CapitalFlight

3 years ago

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

$ 0.00

Koush

3 years ago

Yours sounds better.

$ 0.10

ColinTalksCrypto

3 years 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

JonathanSilverblood

3 years 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

jtoomim

3 years ago

Do you want to be responsible for time-locked transactions not executing correctly?

As a smart contract developer I can tell you that the "additional marginal cost" as you put it, might not be as small as you think.

Do you want to explain to people with recurring Mecenas payments, why their monthly payouts got even less accurate with a 2 days per month additional drift?

$ 0.21

JonathanSilverblood

3 years ago

Because despite prior work, yet again ABC is going "This is the way it's going to be"

$ 0.51

OverlordQ

3 years ago

How can 'despite prior work' be accurate? Again: this is based on ASERT, it credits the work of Jonathan Toomim and Dr. Lundeberg in the text.

$ 0.50

Marco

3 years ago

Amaury wrote:

While there is a lot of discussion around the DAA, no concrete proposal has reached ABC at the time of this writing...

He did not credit Jonathan Toomim with having had a proposal, only with having suggested a single parameter. Toomim had also written not only a detailed blog, but also a C++ implementation which he sent to Amaury/ABC for review, but they chose to ignore it and rewrote their own DAA with significant differences in implementation which nobody had previously agreed to.

$ 0.51

gotamd

3 years ago

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

Did you even read the thing? Credit was given to Jonathan!

$ 0.00

Nicknameul

3 years ago

but don't we want to have a predictable emission schedule?

This does not provide any more predictability then the alternative. It rectifies a broken assumption about the past emission by temporarily breaking the same assumption about future emission.

the additional marginal cost of fixing drift

You make it sound like there's barely no effort necessary to verify this algorithms claims.

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

I have for a while now told people that perfectionism and not-invented-here syndrome is a very bad situation to be in, and this is what the proposal here looks like: instead of getting a community and cross-node collaboration completed - a single entity choses that perfection is required (must fix previous drift as well) and instead of actaully discussing it on the DAA developer meeting and proposing solutions for discussions goes ahead and puts out a invented-here and therefor will-be-used solution.

$ 1.10

JonathanSilverblood

3 years ago

Yes, this situation is very aggravating.

$ 0.00

WatchingStuff

3 years ago

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

$ 1.15

CapitalFlight

3 years ago

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

$ 0.76

mkomaransky

3 years 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

Nicknameul

3 years 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

molecular

3 years 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

JonathanSilverblood

3 years 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

freetrader

This user is who they claim to be.
We have manually verified this user via some other channel.
Proof

3 years 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

Fernando

3 years 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

WatchingStuff

3 years 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

molecular

3 years ago

Great and informative article

$ 0.00

Saanimustaf1

3 years 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

lugaxker

3 years ago

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

$ 0.00

ColinTalksCrypto

3 years 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

georgedonnelly

3 years ago

wow jesus christ you need to go away

$ 0.00

CashAnarchist

3 years ago

go away

$ 0.00

CashAnarchist

3 years 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

doc

3 years ago

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

$ 0.00

Koush

3 years ago

[deleted]

$ 0.00

doc

3 years 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

Koush

3 years 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

gotamd

3 years 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

jtoomim

3 years 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

Koush

3 years 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

jtoomim

3 years ago

Hats off to you Jonathan.

$ 0.00

rnbrady

3 years 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

ZakMcRofl

3 years ago

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

$ 0.02

georgedonnelly

3 years ago

https://gitlab.com/jtoomim/bitcoin-cash-node/-/commit/fd92035c2e8d16360fb3e314b626bf52f2a2be67

$ 0.35

OverlordQ

3 years ago

https://read.cash/@JavierGonzalez/why-bitcoin-cash-need-the-bmp-1a6ab975

$ 10.50

JavierGonzalez

3 years ago

Great work!

$ 0.56

Omar

3 years ago

These is very good event though

$ 0.00

welskie

3 years ago

$ 0.50

JavierGonzalez

3 years 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

Bitraph

3 years ago

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

$ 0.00

Clay

3 years ago

BCH ✌

$ 0.00

akbcrypto

3 years ago

All singn point to right.

$ 0.00

Jakir

3 years ago

Bitcoin ABC is therefore moving forward with the Grasberg DAA.

$ 0.00

Garvit

3 years ago

Nice job

$ 0.00

3 years ago

great BCH

$ 0.00

aany

3 years ago

How can i be part of the Bitcoin Cash Community?

$ 0.00

Bestie

3 years ago

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

$ 0.00

georgedonnelly

3 years ago

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

$ 0.00

CashAnarchist

3 years 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

Koush

3 years ago

Yeah. fire him and his ABC dictatorship.

I am sick of your ABC shilling

$ 0.00

CashAnarchist

3 years ago

blah.

$ 0.00

Koush

3 years 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

Sarahmay

3 years ago

Oh! There are no specs?... again... History tends to repeat itself. Guys, code is not specification!

$ 0.11

Fernando

3 years ago