Dark secrets of the Grasberg DAA

103 6249
Avatar for jtoomim
3 years ago

On July 23, 2020, Bitcoin ABC announced Grasberg, a new difficulty adjustment algorithm (DAA) for Bitcoin Cash, to much fanfare. The announcement certainly sounds exciting, and mentions several advantages to the new DAA. But the announcement is more noteworthy for the facts that it omits. There are some very important facts about the Grasberg DAA that Bitcoin ABC did not mention. The Bitcoin Cash community should be aware of these facts before making a decision about whether to accept Grasberg, or whether to choose the alternative instead.

In this article, I will present evidence for four types of arguments against Grasberg:

  1. Grasberg will have negative practical effects on Bitcoin Cash (sections 1-2)

  2. Grasberg will compromise the economic principles of Bitcoin Cash (sections 2-3)

  3. Grasberg is a dangerous political tool of Bitcoin ABC (sections 3-6)

  4. Grasberg is a technically inferior option to fix the DAA issue (sections 7-10)

In this article, I present a large number of serious claims against Bitcoin ABC. These claims require verification. But serious claims demand severe action. If even a few of my claims are accurate, then Bitcoin Cash should respond quickly and strongly to respond to this threat.

The first few of Grasberg secrets concern the mechanism for correcting historical drift. Bitcoin ABC did not clearly state what the costs of this system would be, and they are significant.

1. Grasberg will cause 11.25 minute block times for the next 6.5 years

Grasberg will cause blocks to be mined 12.5% slower until April 2027. This means:

  • Confirmations will be 12.5% slower

  • Deposits to exchanges will be 12.5% slower

  • The 50-tx chain limit will be 12.5% more restrictive

  • BCH miners will earn 11.1% less revenue

  • BCH will have 11.1% less hashrate and security

  • Height-based nLockTime transactions will be unlocked 12.5% later

The 11.25 minute block times is not a mistake. It is the intended effect of Grasberg's computeTargetBlockTime(...) function. Bitcoin ABC knew that Grasberg would produce 11.25 minute block times, and they chose not to mention it in their announcement.

Our current DAA, cw-144, was added in November 2017, and has done a good job of keeping blocks coming at very close to 600 seconds per block without drift. ASERT would do as well if not better. Grasberg would cause blocks to take 675 seconds until 2027. This graph shows a 8064-block moving average of recorded and simulated block intervals. The cw-144 projection was performed by repeating the last 50,000 block intervals indefinitely. An interactive version of this chart is available at http://toom.im/bch/grasberg_block_interval.html

2. Grasberg will change the BCH coin emission schedule

Bitcoin ABC claims that the main motivation for Grasberg is to avoid redefining the emission schedule. They claim that this is the main reason why ASERT can not be an option. To quote their article:

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

Unfortunately, they have it backwards. The only way to avoid redefining the coin emission schedule is to use the *most recent* (pre-fork) block as a reference point. This is what my ASERT proposal does, but it is not what Grasberg does.

Most people who are not experts in DAAs (and ASERT in particular) may find this terminology confusing and unfamiliar, and may find a theoretical argument difficult to follow. Fortunately, there is much simpler way to explain this issue: with data. Data don't lie.

We can see which algorithm actually redefines the coin emission schedule by looking at the coin issuance schedules for Grasberg, ASERT, and the current status quo (cw-144).

After the Nov 2020 hard fork, Grasberg's coin issuance will drop by 12.5% until 2027, whereas the current DAA (cw-144) and ASERT have coin issuance schedules that are so similar as to be indistinguishable in this simulation without zooming way in. An interactive version of this chart is available here: http://toom.im/bch/grasberg_coin_issuance.html

The current coin emission schedule is 900 BCH per day (6.25 BCH * 144) until the next halving.

The coin emission schedule for ASERT is also 900 BCH per day until the next halving. ASERT preserves the existing coin emission policy, and is nearly indistinguishable in coin emission from the current DAA (cw-144) without zooming in. That's because ASERT is designed to use the last cw-144 block as its reference; ASERT simply extends the current coin emission policy, but with greater precision and without the 24.5-hr oscillations.

The coin emission schedule for Grasberg is 800 BCH per day (6.25 BCH * 144 /112.5%) until the next halving. Grasberg defines an entirely new coin emission policy. Grasberg generates blocks 12.5% slower, which gives us 11.11% fewer coins for the next 6.5 years, after which it delays all halvings by about 8 months. This new, unexpected coin emission schedule is defined by several new, arbitrary numbers. Nowhere in the Bitcoin white paper or original source code was the number 12.5% or 675 seconds listed. The consequent 6.5 year length is likewise arbitrary. These numbers were chosen by Amaury Séchet and Bitcoin ABC without explanation. The 12.5% number in particular is eerily familiar.

If Bitcoin Cash is to be hard money, then it must resist attempts by developers to arbitrarily change the coin emission schedule. If we allow Amaury Séchet to change the schedule now, that sets the precedent that changing the timing or quantity of coin issuance should be within his power. It makes him akin to a central banker or a chancellor, handing out free money to hodlers. With that precedent, and when this change expires in 6.5 years, we might find that Bitcoin ABC's chancellor is on the brink of a second bailout.

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

3. Grasberg crosses the line from technology to politics

The coin emission schedule determines how new wealth is distributed. Changes to the coin emission schedule is changing the distribution of wealth. This is a major red flag.

Changes like Grasberg's 11.1% reduction in coin issuance rate are extremely dangerous precisely because they are attractive to many people. It's easy to rationalize Grasberg as benefiting hodlers via a 11.1% reduction in issuance and inflation. A person who already has a large stash of BCH -- for example, if they had mined a lot of BCH during Aug 2017-Nov 2017, when miners were earning up to 3.5x as much BCH per day as Satoshi intended -- then they might be interested in seeing a reduction in issuance to give them a short-term boost in their investment's value and make it easier for them to cash out.

We should not let ourselves be swayed by arguments like these, because coin issuance is inherently a zero-sum game. For every dollar of direct benefit that a coin issuance change gives to old users and hodlers by allowing them to sell at a temporarily higher price, there is a dollar of direct detriment to new users by forcing them to buy at a temporarily higher price.

Furthermore, any attempt to manipulate the value of the currency by changing inflation is bound to backfire. By changing coin issuance this one time, Bitcoin ABC would be sending a strong signal that the current economic and monetary rules of Bitcoin Cash are not permanent, and that any coins they buy are for a supply that is subject to change. Current holders will lose faith in the currency's future, and will be inclined to sell while the price is still high. Potential buyers will lose faith in the currency's future, and will be less inclined to buy. A currency is only as strong as its promise of future value.

Bitcoin is supposed to be censorship-resistant worldwide electronic cash, to bring economic freedom to the world, and to free people from the economic control of corrupt and self-serving governments, not to be an investment vehicle for early adopters to get rich. In order to accomplish its goals, Bitcoin's rules need to be kept fair and economically consistent. We should not allow changes to Bitcoin Cash's economic policy that take from future users to enrich the present ones. If we follow this path, there likely won't be any future users to take from.

4. Grasberg's historical drift correction is unpopular among BCH developers

On Monday, July 26th, a development meeting was hosted by Future of Bitcoin Cash on the BCH DAA issue. The entire 1h50m meeting was dedicated to the historical drift correction issue. This meeting was attended by the following ten developers:

  • Amaury Séchet, the lead developer of Bitcoin ABC

  • Antony Zegers, a developer of Bitcoin ABC

  • Zawy12 (Scott Roberts), a non-BCH developer who specializes in DAAs

  • Jacob Eliosoff, a non-BCH developer who specializes in EMAs, and who was the first to discover ASERT

  • Jonathan Toomim (myself), an independent BCH developer

  • Jason Dreyzehner, a developer of an SPV wallet at bitauth.com

  • Chris Pacia, one half of the BCHD team

  • Josh Ellithorpe, the other half of the BCHD team

  • Andrew Stone, the lead developer of Bitcoin Unlimited

  • Freetrader, the lead developer of BCHN

After having discussed the drift issue for nearly two hours, an informal poll was done of the developers about whether or not they supported the proposal to do historical drift correction. The results were:

  • 2 in favor (Both Bitcoin ABC devs)

  • 2 abstentions (both non-BCH devs expressed criticism, but did not vote)

  • 6 opposed (everyone else)

Only 8 BCH developers were present in this meeting, but sentiment among the broader development community seems similar. Some of the developers who have made statements opposing historical drift correction include:

Besides Amaury and Antony, those in favor of drift correction, that I'm aware of, include:

  • Joannes Vermorel (via the [WG] Difficulty Adjustment group on Telegram)

The fact that this proposal appears to be supported only by Bitcoin ABC, and garners strong and near-universal opposition from other developers, suggests that ABC's attempt to push Grasberg's historical drift correction through in the November upgrade could result in a chainsplit.

5. A concrete proposal had reached ABC at the time of their writing

ABC's Grasberg announcement began with the following paragraph:

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.

That claim is simply false.

I submitted my team's proposal for aserti3-2d on July 8th at 04:55 UTC -- a full 15 days before Bitcoin ABC announced Grasberg. Our proposal, aserti3-2d (a cubic integer approximation of ASERT with a 2-day half-life), was very concrete, and included both a Python3 implementation and a C++ implementation built on top of the BCHN full node implementation.

When Bitcoin ABC made the above statement, they were flooded with comments that called out the falsehood on Amaury Séchet's read.cash article and again on Reddit. Bitcoin ABC has not apologized for their error.

Our July 8th proposal and implementation had attracted immediate attention and code review from many BCH node developers, including Flowee (Tom Zander), Knuth (Fernando Pelliccioni), BCHN (freetrader and mtrcyz), and Bitcoin Unlimited (Andrea Suisani). The proposal garnered a lot of excitement, general approval, and collaboration from most of the BCH development community, and several nodes have already begun integrating the code. However, we did not get any code review from any ABC developers.

I sent links to my code to two of ABC's developers (Antony Zegers and Amaury Séchet) several times, but they never tested or reviewed the code. From July 13th-15th, Amaury Séchet asked me some questions about the contents and design of the aserti3-2d algorithm and code, which I answered promptly and fully.

The purpose of these questions does not appear to have been to help them perform code review, or to adequately simulate and test my proposal. They didn't have time to do that, because they were too busy secretly developing Grasberg. A lot of Grasberg's design and features is based on my team's research, or is directly derived from my implementation. This includes the fundamental premise that the DAA is broken, that a new DAA can solve the issue, that Bonded Mining is not an appropriate choice, that ASERT or RSERT is likely to be the best choice, and the use of the 2^(x+n) = 2^(x) * 2^(n) identity to help with the integer approximation step.

I am not bothered by the fact that I did not receive as much credit for my work as they should have given me. What bothers me is that Bitcoin ABC stonewalled my proposal and denied its existence, while simultaneously copying its critical features, and finally attempted to take primary credit for fixing the DAA and the oscillation issue.

Furthermore, their announcement provided Grasberg as a done packaged deal, a fait accompli, rather than as a proposal:

Bitcoin ABC is therefore moving forward with the Grasberg DAA.

I try to always assume good faith in my interactions with other developers in open source projects, but I struggle to explain this behavior as being in good faith. These are the facts:

  • Bitcoin ABC was aware of my proposal

  • Bitcoin ABC asked me questions on my proposal

  • Bitcoin ABC publicly claimed the nonexistence of my proposal

  • Bitcoin ABC developed a competing project, using features from my proposal

  • Bitcoin ABC's project shared fundamental properties with and was influenced by my proposal

  • Bitcoin ABC claimed they did not have time to review, simulate, test, and get feedback addressed for my proposal or any other proposals

  • Bitcoin ABC had time to develop, review, simulate, test, solicit feedback, and address feedback for their own proposal, even though it was started much later and was less mature than mine

  • Bitcoin ABC did not announce their project as a proposal, but as a conclusion

Given these facts, I think it is clear that at a minimum, Bitcoin ABC's behavior has been unprofessional and immature. However, it's hard to explain these facts based solely on immaturity. Consequently, I think the BCH community needs to consider the hypothesis that Bitcoin ABC has been acting dishonestly and selfishly.

The most charitable explanation I can give for this behavior is that Bitcoin ABC has a severe case of Not-Invented-Here syndrome (NIH), which causes Bitcoin ABC to prefer to spend extra time developing their own ideas instead of reviewing other's code. However, NIH fails to adequately explain why Bitcoin ABC did not adequately acknowledge the existence of another proposal, nor why ABC presented Grasberg as a fait accompli. This suggests that a less charitable explanation may be more accurate.

To quote developer Andrew Stone of Bitcoin Unlimited:

A greater acknowledgement of the previous work done is probably very important. And in particular in this case to be branded as a whole new algorithm on the outside, but if you look under the covers, it's what Jonathan has been working on for a long time plus some other stuff, you know, makes it look like a steal...

We should consider the possibility that Bitcoin ABC was attempting to copy the core elements of the design of my team's DAA fix in order to take credit for the work and to reaffirm the political power that they had lost after their failed IFP proposal. The historical drift correction proposal and new coin issuance schedule may have been a concession or political compromise to one of their allies or funding sources intended to secure their continued support, or it may have simply been intended as a wedge to divide the community and allow them to seize control with decisive leadership.

I do not know what Bitcoin ABC's true motivations were. I hope they were for the best. Ultimately, it does not matter: Although we can hope for the best, we must always be prepared for the worst.

6. Grasberg is a big step on the path to corruption

Bitcoin was created largely in response to the corruption in the world's financial system that led to the 2007-2009 financial crisis. Bitcoin was designed to be resistant to government manipulation, censorship, and corruption. Bitcoin's publication was so long ago that many people have forgotten how Bitcoin achieved these properties, and have assumed that Bitcoin Cash will always have them. This is not guaranteed, and we are dangerously close to losing them.

Bitcoin's resistance to manipulation and corruption came as a result of a few properties of the system:

  1. Bitcoin's main economic parameters were defined by math and code, and were thought to be immutable.

  2. The system was not owned or controlled by anybody; there was no person who could be coerced.

Bitcoin Cash does not have those properties any longer. We have a hard fork every 6 months as directed by a "benevolent" dictator.

Grasberg takes us two steps further. If Grasberg is activated, it will demonstrate two new facts:

  1. The main economic parameters of Bitcoin Cash, like the coin emission schedule, can be intentionally changed.

  2. Amaury Séchet and Bitcoin ABC are in control of Bitcoin Cash, and have the sole and ultimate authority over protocol changes.

This makes Bitcoin Cash vulnerable to bribery and coersion. It tells any interested parties that if they want to change the core economic parameters of Bitcoin Cash, all they need to do is to get sufficient leverage against Amaury Séchet -- either via bribery or via a $5 wrench attack.

Source: https://xkcd.com/538/

It does not matter if Bitcoin ABC is currently corrupt. It does not matter if they were bribed or coerced into making this change. If we want our economic system to be resistant to corruption, we need proactive security, not reactive security. We need to prevent any actions that could be the result of bribery, coersion, or corruption. And we need to prevent any actions that would encourage them, or enable them.

Consider the following hypothetical scenarios.

Scenario A: Let's say that there is one or more large miners who mined a lot of blocks during the EDA era, and now has a large stash of coins that they want to appreciate in value. This miner may also wish to have greater control over the Bitcoin Cash blockchain, so that they are able to police it more effectively. This miner might advocate for a reduction in the BCH block issuance by 12.5%. This would not adversely affect the miner's revenue, since they can just switch some of their hashrate over to mine BTC instead. Since BCH gets only 2.5% of the total SHA256 hashrate, they would lose only 11.11% * 2.5% = 0.27% of their revenue. Meanwhile, their BCH holdings might appreciate 11.11%. If that individual or company has $200 million at stake, they might expect to gain returns of should their preferred policy be enacted. That gives them $21.67 million of benefit if they should succeed. Let's say that by donating $1.8 million to the reference implementation, this person has a 25% chance of gaining enough lobbyist influence in order to get his preferred change enacted. This results in an expected return on investment of $3.6 million for the miner and $1.8 million for the developer.

It's natural for individuals, businesses, or governments to want to make these changes to Bitcoin Cash. Blaming miners for wanting to get rich will not help us. If Bitcoin Cash is to be kept uncorrupt and free, we need to ensure that they can't make them.

Scenario B: Let's say there is a company, individual, or government with a significant financial interest in seeing a specific cryptocurrency platform collapse. Perhaps they are a major BTC or BSV holder, and expect their other cryptocurrency to gain market share in that event. Or perhaps they are a major bank and see cryptocurrencies as a threat. If they have $1 billion at stake, and they stand to gain 10% if they destroy Bitcoin Cash's market share, that's $100 million of potential gain. Let's say that by donating $2 million in funding a development team with a history of divisive behavior, and demanding a controversial policy be implemented, this entity has a 5% chance of triggering a chainsplit that would fragment the community, stagnate growth, and eliminate Bitcoin Cash as a threat. This results in an expected return on investment of $3 million for the attacker and $2 million for the developer. Both parties can improve their income by shorting BCH prior to the policy's deployment.

In both of these scenarios, there is no way for the general public to know that such an arrangement has been made as long as all parties involved cover their tracks appropriately. We should not wait for proof of malfeasance. The fact that these attacks are possible is reason enough why we need to act now.

This is a parody, and is not the current Bitcoin ABC website. It is intended to be funny. But in order to be funny, humor needs to have an element of truth to it.

7. Grasberg was not properly simulated

In February, I did two weeks of development work on improving and extending a good multi-coin mining simulator to test out different DAAs and show conclusively that a DAA change could fix BCH's hashrate oscillation issues. I spent most of June again working with that simulator along with Zawy12 and Jacob Eliosoff to compare all known candidate DAAs to identify which ones had the best balance of performance, simplicity, and attack resistance. I consider detailed and well-documented simulations to be critical for any serious protocol change proposal.

The Grasberg announcement said this about Grasberg's testing:

Bitcoin ABC has already run simulations and real-world testing of this algorithm

Several developers in the DAA working group on Telegram asked for a copy of the simulations that Bitcoin ABC claimed to have done on Grasberg.

All we got from Amaury was this spreadsheet. No explanation, no description, no justification, no source code. Just a spreadsheet with a bunch of hard-coded values. Amaury Séchet went a step further and explicitly told us not to trust anything in it.

This is sloppy and unprofessional, and does not reflect well on Bitcoin ABC's competence and leadership quality.

8. Grasberg's simulation performance is inferior

So I did my own sims of Grasberg. I integrated Grasberg into my own simulation framework. A live web copy of my simulator is running at http://ml.toom.im:8051/.

The Grasberg proposal has a few different variants in my simulator. The first one is labeled as grasberg-288, and emulates the behavior of Grasberg during the first 6.5 years while Grasberg targets a 11.25 minute block time. The second is grasberg-neutral-288, and reflects Grasberg's behavior after Grasberg has returned to a 10 minute block time target. I also included the grasberg-nodrift-288 variant to simulate how Grasberg would perform if the drift correction code were ripped out entirely, as well as variants using different time constants for different resonsiveness/smoothness tradeoffs.

Grasberg's performance needs to be separately analyzed in two conditions:

  1. Over the first 6.5 years of operation, while grasberg's performance is dominated by the 11.25 minute target block time

  2. After Grasberg has neutralized the drift backlog against its genesis block-derived schedule

Scenario 1 seems pretty straight-forward. Grasberg mines blocks slower than aserti3-2d and similar algorithms, and consequently gets worse confirmation times and mining fairness performance. But it's a bit worse than we expected: rather than performing 12.5% worse on confirmation times and mining fairness, grasberg-288 performs about 19-25% worse.

grasberg-288 shows a delay in all respects compared to aserti3-2d in this simulation, simply because each block takes 12.5% longer. (This simulation changes the exchange rate after each block on a predefined pattern, which is why grasberg-288's price (not shown) and difficulty graphs looks like a horizontally stretched version of aserti3-2d.)

Confirmation times are consistently longer with grasberg-288, due in part to the 12.5% slower block time.
Confirmation times are 19% longer on grasberg-288, despite block intervals only being 12.4% longer. Also, the profitability advantage for switch mining is 25% higher for Grasberg. This indicates that the longer block interval is not the only problem with Grasberg.

When we switch to scenario 2, the algorithms start to look more similar, but a performance difference persists.

After 6.5 years have elapsed and grasberg returns to a 600 second block interval target, its difficulty graph looks very similar to aserti3-2d, but they aren't quite equivalent. Small differences persist.
Grasberg's confirmation times remain slightly higher than aserti3-2d throughout the test run. Grasberg also has a larger spike in confirmation times at 35 days and a smaller one at 140 days. This shows that the two algorithms are similar, but not identical.
Between the two algorithms, in this test, Grasberg is unequivocally worse in confirmation time and mining fairness.

Once Grasberg has returned to a neutral 600 seconds per block, its performance is much improved. Across the board, grasberg has decent performance. However, it still does not perform as well as aserti3-2d.

I believe the main reason why Grasberg underperforms in these tests is because of Grasberg's choice of time constants. Bitcoin ABC did not follow my advice correctly on the choice of half-lives and time constants. (Ironically, the advice to use a 2-day half-life is the only thing that Bitcoin ABC credited me for, despite the fact that they did not follow the advice.) The source of this confusion appears to be the distinction between a time constant (or relaxation time), which would be tau in the natural exponential function e^(x/tau), and a half life, which would be lambda in the base-2 exponential function 2^(x/lambda). I recommended the use of a 2-day half-life, and used that in my code; however, Bitcoin ABC ended up using a 288-block (2-day) time constant. The conversion from a time constant to half-life is done by multiplying by ln(2), so they ended up with a 199.6-block half-life. I informed Bitcoin ABC of this error on July 23, 2020, the day Grasberg was published. Amaury acknowledged the error, but has not fixed it. This appears to be because he did not simulate it in a scenario in which the difference manifests.

9. Grasberg is far more complex than ASERTI3-2D

Grasberg is far more complicated than it needs to be, in both implementation and design. This is readily apparent by comparing the aserti3-2d and Grasberg code side-by-side, but the complexity goes much deeper than that.

A mature aserti3-2d implementation on the left, and an early revision of Grasberg on the right. Both algorithms are integer-only. The Python3 implementations are shown here in order to strip away boilerplate code and show the core algorithm complexity. While the last week's revisions of Grasberg have simplified it somewhat, it remains far more more complicated than it needs to be and more complicated than aserti3-2d is.

Mark Lundeberg (the co-inventor of ASERT) wrote a detailed review of the Grasberg implementation on July 24th. His review repeatedly raised concerns about Grasberg's complexity:

I find the detailed algorithm is unnecessarily complex for what it accomplishes, i.e., the same thing could be done much simpler. ... As alluded to above, I think the algorithm has way more complexity and computation than is needed. deterministicExp2 is an approximation to 2^x - 1, for 0<=x<1, in fixed point math. It is a compound curve made up of 16 quadratic segments with discontinuities. It has a ~1 ppm accuracy (if I have translated it correctly). I find this algorithm is much more complicated than is needed for its accuracy level, but also I don't know why this accuracy level was selected in the first place:

10. Grasberg's complexity adds vulnerability to attacks

Fundamentally, Grasberg is neither absolute nor relative, neither ASERT nor RSERT; it's both simultaneously. Grasberg has a relative scheduling (RSERT) feedback loop for controlling mining difficulty over short time spans, as well as an absolute scheduling feedback loop that regulates the targeted block interval.

Not only does this dual loop system increase the amount of code Grasberg requires, but it also makes the behavior of grasberg more complex and adds vulnerabilities. While neither ASERT nor RSERT by themselves will oscillate, combining the two into a hybrid system does have oscillatory potential. The problem arises because the two parallel feedback loops can operate with different delays. The fast loop can complete its response to a perturbation in block interval while the slow loop is only getting started. This can leave a residual effect from the slow loop that can cause overshoot, ringing, and potentially oscillations. In the specific case of Grasberg, this oscillation is fortunately mitigated by the values that were chosen for some of the constants. Specifically, in the computeTargetBlockTime() function (which determines the slow loop's feedback and provides the drift correction), the constants tau and X_CLIP need to have high and low values, respectively, in order to prevent oscillation. If either one is changed enough, or if both variables are changed a moderate amount, then some instabilities can result. With larger changes, the oscillations become somewhat severe, as shown in the simulation run below with tau = 600 and X_CLIP = 2729822324.

Grasberg is relatively stable in normal circumstances, but if one or two constants in the code are changed, moderate to severe oscillations can result. It may also be possible to produce oscillations with Grasberg in attack scenarios.

While the default values of tau and X_CLIP are sufficient to prevent any oscillation or bad behavior in natural mining scenarios, they can be successfully manipulated in adversarial scenarios. For example, there's a mining attack I call the fast forward attack which is exacerbated by Grasberg's dual feedback loop design.

The fast forward attack is an attack that all DAAs seem to be vulnerable to, albeit to different degrees. In the fast forward attack, a miner will create a secret chain which they mine for several days with 101% as much hashrate as the honest chain -- this part is somewhat similar to the reorg attacks that have been attempted against coins like Bitcoin Gold over recent years. But there's a twist: when the miner starts a fast-forward attack, they manipulate the timestamps of their blocks to be very close to the time at which they intend to publish the blocks. This fast forwarding of the timestamps causes the difficulty to drop, allowing for most of the blocks to be mined at a lower difficulty. Once the attacker gets to the same height that the honest chain will end at, the attacker will have used less hashrate to get the same number of blocks and coins. The attacker can then mine a few extra medium-to-high difficulty blocks until their chainwork exceeds the honest chain's. This gives them a few extra blocks overall. The amount of extra profit the attacker gets depends on the DAA and the exact mining strategy used.

The fast-forward attack in mining is similar to a problem in physics, where gravity means that the fastest path between two points is not necessarily a straight line. It's often faster to descend rapidly first to gain speed. The fast-forward attack is similar: attacking miners can manipulate their timestamps to quickly drop difficulty and increase their block production speed at the beginning of a long-term reorg attack.

My best attack against the cw-144 algorithm gets 209 blocks with as much work as 145 honest blocks, for 44% extra profit, whereas the aserti3-2d algorithm only allows 1138 blocks for the price of 816, or 39% -- that's a lower profit ratio for a larger (and harder) gamble. With Grasberg, the severity of the vulnerability depends on the computeTargetBlockTime() drift correction in the slow feedback loop. With it enabled, and after 6.5 years have elapsed and Grasberg is at equilibrium, Grasberg can be fast-forward attacked for 52% extra profit. But if computeTargetBlockTime() is bypassed (made to return 600 sec no matter what), then that extra vulnerability disappears, and Grasberg can only be attacked for 39%, which is same as aserti3-2d.

The fast-forward attack is not a particularly worrisome attack. Since it requires 101% of the hashrate and a multi-day reorg, whenever it is possible to perform it there are usually much more serious issues that we need to worry about. Also, the fast-forward attack is prevented by the 10 block finalization rule in ABC and BCHN. But it serves to illustrate the complexity of Grasberg's response, and suggests that there may be other potential attacks which are more practical and which are yet to be discovered.

11. Conclusion

In this article, I have shown Grasberg to be inferior in 10 different respects. In rough order of importance:

  1. Grasberg will be 12.5% slower for 6.5 years.

  2. Grasberg redefines the coin emission schedule, and sets Bitcoin ABC up as the central bank of BCH.

  3. Grasberg changes the distribution of wealth.

  4. Grasberg is widely opposed, especially in the BCH developer community, where 75% of DAA developers opposed it in a recent straw poll.

  5. Grasberg's announcement was dishonest, ignored aserti3-2d, and appears to have been an attempt to steal credit from others for political gain.

  6. Grasberg opens the door for BCH to be controlled via bribery and coersion.

  7. Grasberg was not very well simulated by its creators.

  8. Grasberg does not perform as well in simulations as the best-known proposals.

  9. Grasberg's code is far more complex than a DAA needs to be.

  10. Grasberg unnecessarily adds technical vulnerabilities to attack.

In the process of showing this, I have also shown disturbing patterns in Bitcoin ABC's behavior:

  1. Bitcoin ABC has repeatedly misled the public. First, they withheld information about the 11.25 minute block times. Second, they falsely claimed that ASERT changes the coin emission policy, when that's actually what Grasberg does. Third, they claimed the nonexistence of other proposals.

  2. Bitcoin ABC has repeatedly demonstrated technical incompetence and unpreparedness with Grasberg. This has been shown with the lack of solid simulation results, the potentially oscillatory design, the algorithm's complexity, and the algorithm's susceptibility to attack.

  3. Bitcoin ABC has demonstrated a complete disregard for the positions and contributions of other Bitcoin Cash developers.

  4. Bitcoin ABC appears to be taking a "You do you. We will do us" approach to software development. They appear to have developed Grasberg in response to aserti3-2d, and may be intentionally escalating to a chainsplit.

  5. Bitcoin ABC is performing one of the gravest sins a developer can make: they are attempting to push through a change to Bitcoin's economic and monetary policy, and take on the role of a central bank.

  6. Bitcoin ABC appears to be attempting to consolidate political power over Bitcoin Cash. Should they succeed in doing so, they will likely be able to leverage their power for money.

Amaury Séchet has done many good things for Bitcoin Cash in the past. In 2017, he and freetrader created Bitcoin Cash, and Amaury has worked hard for three years to maintain Bitcoin Cash's most popular full node, and to keep the code secured against attack. He helped us free ourselves from the control of Blockstream, after they transitioned Bitcoin's economy to a high-fee constrained-blocksize regime and attempted to push Bitcoin's users toward Blockstream's own product, Liquid. For his help with that, we will always be grateful to Amaury.

But over time, he has allowed his ego to grow unchecked, and has recently come to believe that he deserves more. In order to get what he thinks he deserves, he has attempted to consolidate control over Bitcoin Cash, and then leverage that control for income. First, he attempted to openly redistribute wealth to himself with the IFP, and his attempt was rejected by BCH's users. I respect the honesty and directness of the IFP, and do not fault Bitcoin ABC for it. Nonetheless, BCH sent a clear message to Bitcoin ABC in February: Thou shalt not change the distribution of wealth. Unfortunately, Bitcoin ABC seems to have not gotten that message, and is once again attempting to change the distribution of wealth. This time, there is the possibility of a path back into their own coffers, but no direct evidence of such a path. That said, there is direct evidence of dishonesty and subterfuge from Bitcoin ABC in other respects; and there's evidence that they're hiding something, and have not been forthright about their motivations for Grasberg.

12. What happens now

There is no coming back from this for Bitcoin ABC as an organization. This is the end-of-life for Bitcoin ABC.

Unfortunately, the severed head of a snake can still bite. As Bitcoin ABC collapses, they will still be able to do some harm to Bitcoin Cash in their death throes. It will likely be a few weeks before Amaury Séchet realizes that he has lost, and in the mean time, he will continue to struggle for dominance.

Bitcoin ABC has been playing a game of brinkmanship. They are using the fear of a chainsplit to try to convince everybody to conform to their leadership and their solution as a Schelling point. This fear of a chainsplit increases their chance of winning without a chainsplit: in the game of chicken, the person who swerves first loses. To counter this, we have two good options. We can remove their power to generate a meaningful chainsplit, and we can create a stronger Schelling point. If we do this properly, then we can change the game: the person who plays chicken on a motorcycle against a freight truck loses no matter what.

To remove Bitcoin ABC's ability to plausibly threaten a chainsplit, I recommend all Bitcoin Cash businesses, users, and investors take the following steps:

  1. Every business, miner, and individual in the BCH ecosystem needs to stop running Bitcoin ABC software immediately, and switch to another full node implementation. Without users, Bitcoin ABC will have no bargaining power, and they will be unable to use the threat of a chainsplit to get their way. If you are running ABC, you need to switch immediately. It does not matter which node you choose; all are led by reasonable people. Depending on your business, you may want to choose:

    • BCHD for its advanced gRPC API and Neutrino support

    • Flowee-the-Hub for its cutting-edge performance and API extensibility

    • Bitcoin Cash Node (BCHN) for the thoroughness of their code review, or as a drop-in ABC replacement

    • Bitcoin Verde for an integrated full node/block explorer platform

    • Knuth for a node-as-a-library interface from several programming languages

  2. Revoke funding from Bitcoin ABC. If you are making monthly contributions to Bitcoin ABC, cancel them. Contribute financially to other projects if you can.

  3. State publicly and clearly that you will not follow Bitcoin ABC or Grasberg in the event of a chainsplit, and will sell coins on any Grasberg chain. (This one is easy for me.)

  4. If you can, offer jobs to Jason Cox, Fabien, and Antony Zegers. They're good engineers and good people who have been trying to make the best of a difficult situation.

  5. If Amaury Séchet abandons Grasberg voluntarily, offer him a job as a developer, but not as a manager. Amaury is a good engineer who unfortunately was promoted until he was in a position of incompetence. Do not put him in a position where he will need to frequently review the work of others. Let him return to what he's good at: writing (but not reading) code.

To create a stronger Schelling point, what we need to do is simple:

  1. If you prefer prefer aserti3-2d, say so, clearly and unambiguously. Do so as an individual or as a business. This is especially true for developers.

If we do these things, then we will make this transition as smooth as possible.

13. What comes next

On a more personal note, in 2018-2019 I was working on some benchmark projects and Xthinner development work based on Bitcoin ABC, but which I eventually abandoned because even simple changes got stalled in code review. Amaury seemed indifferent to my project, even when I demonstrated 3,000 tx/sec in my benchmark, and never engaged except to tell me that it needed more unit tests. A few months ago, as a way to ease my COVID blues, I decided to try resurrecting some of these projects for BCHN, and the difference in response was incredible. The BCHN devs were enthusiastic about the idea of stress test benchmarks. As soon as I published a merge request with draft code, they pored over it with detailed and simultaneous code review from several different devs on the team. Not only did they find problems in my code that I hadn't thought of, they offered to fix them for me, and then they made good on that offer.

In mid-May, I realized that the deadline was coming soon if i wanted to get the DAA fix done for November, so I shelved the benchmarking/Xthinner stuff for the time being. Given the outpouring of help I had received earlier, as well as the fact that BCHN had always had a DAA improvement on their roadmap, it was an obvious decision to base my C++ aserti3-2d work on the BCHN codebase after I finished my Python3 simulation work.

I never once regretted it. After I published my proposal, developers started asking questions about the aserti3 design decisions in the BCHN slack, including developers for other full nodes like Tom Zander (Flowee) and Fernando Pelliccioni (Knuth). Tom Harding also chipped in in a few cases. On July 14th, after a couple of days of this, I was asked a question from freetrader about an hour after I went to sleep, asking me where and how they should do code review. Being asleep, I didn't respond, and freetrader and mtrycz didn't wait; they just did it on my repository, so I woke up to this. The next night was very different. Instead of comments like "Hey, there are problems X, Y, and Z, and you should add such-and-such unit tests," as I would expect at ABC, what I woke up to was that freetrader had forked my code, started fixing stuff, and started writing unit tests. Over the next few days, this continued back and forth, with each of us copying from each other's branches while the other slept, or occasionally submitting merge requests to each other. It was the kind of rapid, permissionless, chaotic development that open source development is supposed to be. It was productive, and it was fun.

I'm looking forward to getting aserti3-2d merged, fully tested, and ready for activation, because afterward I'll be able to work again on what I've always enjoyed most: scaling Bitcoin. If we can replicate the pattern we had with the aserti3-2d work on stuff like Xthinner and Blocktorrent, I think we'll be able to make some pretty rapid progress. I think I'm pretty good at doing research and coming up with new ideas and developing prototypes, and BCHN and freetrader have shown that they're pretty good at taking prototypes and turning them into well-specified production-ready code.

In a few months, we will be able to put this Grasberg drama behind us, and with a healthy development ecosystem, we will be able to can focus on building a better platform for p2p cash. We'll finally be able to fix all of the issues that Amaury stonewalled, like the 50 tx chain limit issue, building proper system benchmarks, parallelizing code, and adopting better block propagation technologies. Since 2017, Bitcoin ABC has put less work into code performance optimizations than any other full node that I've seen. Once Bitcoin ABC is no longer the network's bottleneck, we should be able to resume scaling BCH again, and turning Bitcoin Cash into something that will make Satoshi proud.

218
$ 1189.79
$ 545.37 from @majamalu
$ 125.00 from @molecular
$ 112.50 from @RogerVer
+ 57
Avatar for jtoomim
3 years ago

Comments

thanks for this insanely detailed article

$ 0.00
3 years ago

Very detailed. We can't allow arbitrary changes no matter what. If BCH can be controlled by a single individual or group we lose all what we seek in the first place. ABC implementations seems greedy now. They did great for years, but sometimes we face the decision of replace what have been working for what is malfunctioning.

$ 0.00
3 years ago

Ever since the Grasberg announcement, something didn't sit right with me, and I've spent some time thinking about, which might have culminated in some article about it, but you've summarized my own thoughts and then brought it even further and more clearly than I could have. The Bitcoin Cash community is lucky to have you, Jonathan.

Thank you.

$ 0.00
3 years ago

Great article Jonathan! I will release a new version of Knuth node this week, supporting aserti3-2d.

$ 5.00
User's avatar kth
3 years ago

I never once regretted it. After I published my proposal, developers started asking questions about the aserti3 design decisions in the BCHN slack, including developers for other full nodes like Tom Zander (Flowee) and Fernando Pelliccioni (Knuth). Tom Harding also chipped in in a few cases. On July 14th, after a couple of days of this, I was asked a question from freetrader about an hour after I went to sleep, asking me where and how they should do code review. Being asleep, I didn't respond, and freetrader and mtrycz didn't wait; they just did it on my repository, so I woke up to this. The next night was very different. Instead of comments like "Hey, there are problems X, Y, and Z, and you should add such-and-such unit tests," as I would expect at ABC, what I woke up to was that freetrader had forked my code, started fixing stuff, and started writing unit tests. Over the next few days, this continued back and forth, with each of us copying from each other's branches while the other slept, or occasionally submitting merge requests to each other. It was the kind of rapid, permissionless, chaotic development that open source development is supposed to be. It was productive, and it was fun. 😂😂😂

$ 0.00
3 years ago

And it was right to do. BCH needs development, yes, good coders, yes, funding, of course, but it really needs to remain open and united towards a common goal (no need to mention what the goal is, we all know, yet some seems to forget).

$ 0.00
3 years ago

very good article. its Great article Jonathan! plese support me. thank you Sir applying to translate your article to Bangla.

$ 0.00
3 years ago

And you nailed it !!

$ 0.00
3 years ago

"Bitcoin ABC has repeatedly misled the public."


Whosoever benefits from a position of authority
has a primary fundamental responsibility to be honest.
Anything dishonest annihilates any claim to authority.

$ 0.00
3 years ago

Best thing i've read in awhile!

$ 0.00
3 years ago

There's no better way to write it. One can hope that the miners and the exchanges will give up the ABC software

$ 0.00
3 years ago

Jonathan Toomin is the real MVP!

$ 0.00
3 years ago

Very nice but I like your writing but I feel very bad in one place. That is why you are making a post a little bigger. It is very good if you share it in two or three parts.

$ 0.00
3 years ago

Yeah, I've been getting that criticism a lot lately. I heard similar comments on https://read.cash/@jtoomim/bch-fork-proposal-use-asert-as-the-new-daa-1d875696.

Maybe think of it as mental exercise to strengthen your attention span?

$ 0.10
3 years ago

LOL :-)

$ 0.00
3 years ago

I predict Amaury will move over to AVA before the end of the year. And this will be good for BCH. Now that AVA has secured $45million or so, they've stopped being so subtle about it.

$ 0.10
3 years ago

NOW THIS is some serious gourmet shit!

$ 0.00
3 years ago

Very insightful. More than personally pledging to get rid of any ABC coins, we need to convince the wallet developers to implement aserti3-2d. If no wallet supports the ABC side, why would any exchange follow them?

$ 0.00
3 years ago

Utterly brilliant work, jtoomim.

$ 0.00
3 years ago

Good article! From we can learn many things...Grasberg, a new difficulty adjustment algorithm (DAA) for Bitcoin Cash, to much fanfare. Keep doing..... What you are doing ☺

$ 0.00
3 years ago

Under your "Conclusion" section, you mention Grasberg to be inferior in 10 different respects. I would argue there is an additional 11th very important issue. I'd rank it among the top 3:

Bitcoin Cash 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://www.reddit.com/r/btc/comments/i2wefe/i_really_think_that_this_grasberg_developer_guy/

This is a huge deal.

$ 0.20
3 years ago

"burn down ABC no matter the cost to BCH" strategy. I agree ABC is doing a bad job at the moment, but there is no real alternative willing to openly step up and commit to doing it better. There's no better way to write it. One can hope that the miners and the exchanges will give up the ABC

$ 0.00
3 years ago

but there is no real alternative willing to openly step up and commit to doing it better

BCHN, BU, and BCHD are all stepping up and committed to doing better. Two of those three teams have been doing better for years.

BU is a year older than ABC, and is a light year ahead in terms of scaling performance. They have Graphene, parallel block validation, parallel ATMP support, fast GetMiningCandidate API, a fix for the O(n^2) transaction chain issue (i.e. no transaction chain limit), and a ton of other stuff. The only reason why BCH in general isn't benefiting from those features is because BCH's performance has been determined by the weakest link, and that has been ABC for years now.

BCHD made Neutrino, the earliest functional Avalanche preconsensus prototype, and blockchain syncing from UTXO commitments.

BCHN is going to catch up quickly with BU in terms of performance. I'll make sure of it.

Meanwhile, ABC has done ... backports? Yeah, basically a lot of backports from Core. Good work, ABC.

$ 0.01
3 years ago

Thanks for this ❤️

$ 0.00
3 years ago

These things are inherently difficult for common man to understand. You have done well.

$ 0.00
3 years ago

Quotes from the article:

Bitcoin ABC claims that the main motivation for Grasberg is to avoid redefining the emission schedule.

Jonathan , you say:

If Bitcoin Cash is to be hard money, then it must resist attempts by developers to arbitrarily change the coin emission schedule.

I totally agree with this statement however you also say:

The only way to avoid redefining the coin emission schedule is to use the most recent (pre-fork) block as a reference point.

Can you please explain how using the most recent (pre-fork) block as a reference point isn't arbitrary? As far as I can tell, the fork schedule has been arbitrarily chosen by Amaury and as such, choosing a reference point related to this schedule would be arbitrary. Wouldn't it?

In the meantime, you criticize choosing the genesis block as a reference point:

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

I'm sorry but I don't see which reference point would be less arbitrary to choose than the genesis block. It seems certainly less arbitrary than choosing a reference point that is tied to an arbitrary timeline as you suggest.

Also on corruption, you say:

We need to prevent any actions that could be the result of bribery, coersion, or corruption. And we need to prevent any actions that would encourage them, or enable them. [...] Let's say that by donating $1.8 million to the reference implementation, this person has a 25% chance of gaining enough lobbyist influence in order to get his preferred change enacted. [...] Let's say that by donating $2 million in funding a development team with a history of divisive behavior, and demanding a controversial policy be implemented [...] In both of these scenarios, there is no way for the general public to know that such an arrangement has been made as long as all parties involved cover their tracks appropriately. We should not wait for proof of malfeasance. The fact that these attacks are possible is reason enough why we need to act now.

This is a good criticism of the current fundraising model but what do you suggest as an alternative? Don't you agree that developers maintaining and improving the Bitcoin Cash infrastructure should be remunerated for their work? Don't you agree that it would be better if this remuneration was somewhat predictable so the team can plan future development projects? I'm not sure what was your stance on the IFP but most people who opposed it were suggesting to raise money through donations instead, which is exactly the model we have today and which obviously opens the door for the most generous actors to have a direct influence. What would be your ideal funding mechanism for Bitcoin Cash infrastructure development? I don't think ABC likes the idea of being in this situation and the IFP proposal was there to prevent this type of set-up (although we can certainly argue that it came with its own tradeoff). Personally, I suggested a funding mechanism through the emission of tokens that would give access to voting rights.

Otherwise thanks for your article. A lot of good insights/data although I still think that your argumentation on which reference point to choose is flawed.

$ 0.10
3 years ago

Can you please explain how using the most recent (pre-fork) block as a reference point isn't arbitrary?

With ASERT, using the pre-activation block as reference is mathematically equivalent to using the chain tip as reference, or using any block in between as reference. This is explained on the first page of Lundeberg's ASERT paper. Hence there is nothing arbitrary about this choice of reference. All DAA's in the history of Bitcoin (Cash) have always used recent blocks as reference, and using the pre-activation block as reference for ASERT is consistent with that.

$ 0.00
3 years ago

The thing is that this DAA is also correcting the coin emission drift which hasn't been the case in past DAA updates. The parties aren't disagreeing on whether or not to correct drift but on what reference point to use. The reality is that the drift has been taking place since the genesis block so I don't think it's an outrageous thought to consider that the reference point should be the genesis block. It doesn't seem more arbitrary than choosing as a reference point the method that has been used for past DAA. I give a thumb-up to Toomim for his contribution to this new DAA and another one for his comparative analysis of the 2 proposed DAA but I give him a thumb down for his obstinance to destroy the ABC team because Amaury decided not to use his code. Johnathan doesn't seem to understand the rules of the game and instead, he should recognize that Amaury is 100% legitimate to choose whichever code he wants to push to the node implementation led by him.

$ 0.00
3 years ago

The thing is that this DAA is also correcting the coin emission drift which hasn't been the case in past DAA updates. The parties aren't disagreeing on whether or not to correct drift but on what reference point to use.

This is not correct. ASERT corrects neither historic drift nor future drift, like all previous DAAs. Once activated, ASERT drifts very little and in a very predictable way (two days forward every time the hashrate doubles). Grasberg is the only proposal that corrects any drift, and because of the genesis reference, this includes historic drift.

$ 0.00
3 years ago

Another way to get funding that has shared incentives, is to develop a smart contract where you can whitelist developers and that uses an oracle price such that when the funds stored in the contract appreciates in value, some percentage of that appreciation can be sent by the developers.

Then devs get paid when they provide value such that there is appreciation, and there is a consistent and known pool of possible money to get.

$ 1.00
3 years ago

Who would whitelist the developers and who would decide how much a dev gets paid? How would these decisions be made? I assume the funds would be a % of the coinbase.

$ 0.00
3 years ago

The funds would not be a % of the coinbase. It would be voluntary and based on stakeholders choosing to invest part of their appreciation back into the ecosystem.

$ 0.00
3 years ago

How would this be different from the ABC or BCHN donation funds?

$ 0.00
3 years ago

Direct donations require continous effort by the donor and does not provide any guarantees to the donor. This contract method is a one-time setup that doesn't have any cost to the donor unless the donor is also making a profit. The incentives of the donor and the developer gets a shared alignment as to the outcome desired.

$ 0.00
3 years ago

If I understand correctly, the risk will be solely on the devs instead of the financial contributors. If a dev spends time and energy and doesn't achieve the expected outcome, wouldn't he get anything? Shouldn't the cost be on the contributors who chose the wrong dev/project? Who would even gauge if the project is completed with quality standards? How would the quality team be remunerated or trusted? This would incentivize the funding of short-term low-risk projects. Why would a dev take on high-risk long-term projects instead of multiple short-term low-risk projects? I guess it could work for some projects but overall it doesn't seem like a good fit for the type of infrastructure projects that needs to be undertaken. It also doesn't consider the funding of maintenance work that needs to be done. Also, most potential contributors wouldn't have the technical knowledge to smartly allocate their funds to the "right" projects. This approach would certainly lead to design by committee. No thank you for me. We need predictable funding for a team that delivers and trust them to do the job until we can prove that they are failing at delivering.

$ 0.00
3 years ago

It doesn't need to be the only source of funding. It's one alternative out of many, and it has specific benefits and tradeoffs, and when used in conjunction with other means, it helps create robustness.

$ 0.00
3 years ago

It's all good to have multiple sources of funding of course but I'm afraid that still leaves us with an unsolved problem. Maybe it's Bitcoin's sin to not easily allow for the funding of its infrastructure by its community after all...

$ 0.00
3 years ago

you're a hero, Jonathan!

and bchn-team: you are heroes, too!

$ 0.00
3 years ago

Upvote ++;

$ 0.00
3 years ago

This is an article that lets me know what actually happened to the ABC and Cash split .... Today it may have many people who are lost because of the selfishness of ABC. Thanks for the information @jtoomim

$ 0.00
3 years ago

I really wished to know more about grasberg

$ 0.00
3 years ago

It's clear now. If asserti3-2d is being implemented, #BCH will be truly decentralised as a peer to peer with no trusted third party.

$ 0.01
3 years ago

It doesn't need to be the only source of funding. It's one alternative out of many, and it has specific benefits and tradeoffs, and when used in conjunction with other means, it helps create robustness.

$ 0.00
3 years ago

You are hero

$ 0.00
3 years ago

Great article pal

$ 0.00
3 years ago

Thanks Jonathan for all your hard work on this. Leading by example on so many levels.

$ 0.00
3 years ago

leading by example as polically manipulative, hypocritical saboteur? That's what you mean?

How about you guys do him the same way you did Amaury? "It's not about agreeing with him or not, but the way he put it". You think posting this 5 minutes before the next dev meeting was not a political move? A good idea? How about AT LEAST giving him a slap on the wrist, before proceeding to blow smoke up his ass? You guys are always so reasonable I thought?

$ 0.00
3 years ago

The timing was less than ideal. I wanted to get it out earlier, but ... the article just kept demanding more from me as I wrote it. Here's some more context on the timing:

https://old.reddit.com/r/btc/comments/i32k7m/dark_secrets_of_the_grasberg_daa/g08pylu/

Better before than after, at least.

$ 1.00
3 years ago

Oh, I see. You poor soul, you. Here have some more smoke blown up your butt.

$ 0.00
3 years ago

This was great. Keep posting

$ 0.00
3 years ago

I am convinced now, even if it means a painful chainsplit (AGAIN :-( ), potential short/midterm value loss - you're on the right side of history. The biggest job is to convince miners and exchanges and those few devs that are using ABC over the other to switch node before November. That will be hard. Really hard I'm afraid. But attempted it must.

$ 0.00
3 years ago

The BCH community should be very tactical and careful before taking sides with Grasberg or any other alternative

$ 0.00
3 years ago

Wow wow wow, well detailed analysis of Grasberg... Kudos and a very well deserved upvote..

$ 0.00
3 years ago

We need to spread this towards all corners of the BCH Community. And I do need to fix that Change.org petition I made for it.

$ 0.00
3 years ago

Good read!

$ 0.00
3 years ago

Thanks for the additional Grasberg review and for consolidating the many arguments against it into a single piece. I agree that Amaury has been playing a game a chicken with the rest of the BCH community since at least when the IFP was introduced. It's also not clear to me what the precise motivations are for the way ABC stonewalled and deceived everyone else while developing their own Grasberg DAA, but whatever they are it's not good and I can no longer trust ABC as an organization or node as long as it continues to be led as it has been by Amaury.

$ 0.00
3 years ago

I do prefer 10 minute blocks and appreciate the work done on the DAA. I think ABC should change their stated intent. That said, I do not like the politics and threat of splitting the chain if we do not get what we want.

There is still no team offering to do the work ABC has been doing. I see this as an emotionally reactive "burn down ABC no matter the cost to BCH" strategy. I agree ABC is doing a bad job at the moment, but there is no real alternative willing to openly step up and commit to doing it better for the longer term. They just offer to take the power. Yes there is a problem. I see this destructive solution as anti-BCH-inspired and harmful to BCH. We need to replace or fix ABC not just remove it and hope for the best.

$ 0.00
3 years ago

I do not like the politics and threat of splitting the chain if we do not get what we want.

Last time with the IFP debacle, they even tried to blame the IFP-opponents for threatening a split (because (paraphrased): ABC is BCH and ABC needs funding and this is the option on the table and there are no other option, so therefore anyone against the IFP is against BCH and threatening a split).

This time it will be hard to argue the "no other option" part, though. Just saying "there was no proposal submitted" is demonstrably false (thanks for demonstrating once again @jtoomim).

$ 0.01
3 years ago

Nice article

$ 0.00
3 years ago

The claims that ABC = BCH are usually spread by anti ABC forces trying to claim opponents believe that. Of course, there is some truth to it (due to the power of ABC) and they use that truth to hide their false claims wrapped in that truth.

I do think the anti-developer-funding movement was created by anti-BCH forces. That is not the same thing as me thinking ABC = BCH even if you get told that over and over. How they brainwashed real BCH fans into strongly believing the idea that funding our developers using mostly BTC miner's money was a bad idea is a mystery and was amazing social engineering. Apparently they even have you on their side so you may not see the logic of my comment as persuasive.

In my opinion the dark forces that created the anti-IFP movement (that is full of real pro-BCH folks now) were working to split the community and were hoping for a coin split at that time. They did not get it, but, they are very patient. During that attack, they discovered BCH's Achilles heal was Amaury. Since then they have been demonizing him to great effect. They are still pushing for that split and using BCHN as a tool for that goal.

The worst part for me these days is Amaury seems to be helping the attackers by pushing sub-par code in bad ways. I am no expert, so, I could be fooled into thinking that? It looks like he is asking to be replaced. Maybe it is "my way or take this job if you can"? But, I am just guessing due to his silence on "why Grasberg".

$ 0.00
3 years ago

It looks like he is asking to be replaced.

I'm still dumbfounded about his behavior. this is an option, but I don't think it's the most likely one.

amaury could easily end all the drama and get us back on track (and keep most of his powers) by simply accepting asert. I really can't explain why he doesn't do that. if he has the success of bch as primary goal, I think he should do just that to avoid further division and a split. maybe he's trying to prove the hypothesis that a Dev team can be fired. that would be a bold move indeed.

$ 0.00
3 years ago

There is still no team offering to do the work ABC has been doing

You copy-pasted that comment verbatim twice on reddit, too.

https://old.reddit.com/r/btc/comments/i32k7m/dark_secrets_of_the_grasberg_daa/g09v71f/

https://old.reddit.com/r/btc/comments/i37fmz/i_prefer_jtoomims_aserti32d_difficulty_adjustment/g09oy0s/

It seems to be a concern troll comment. This seems like lazy social media manipulation.

See also, where I replied to another similar comment. https://read.cash/@jtoomim/dark-secrets-of-the-grasberg-daa-a9239fb6#comment-ebbe57b9

$ 0.00
3 years ago

Also, I am not saying we should let ABC keep acting like this. I think we need better leadership. I am just asking for the new leadership to step forward and get vetted. They appear to be lurking in the shadows instead. Choosing a leader to fill an already created power vacuum is not good process.

Also, i really liked your stated goal of working on scaling. I hope you get that chance in a productive environment as that is my highest priority for BCH.

$ 0.00
3 years ago

Yes, I commented under the article and copied my comment under some copies of (or links to) your article. I am not calling the spreading copies of your article around inappropriate. I just placed my comment there also for people who just see that copy elsewhere or skip reading your original .

I still see no team offering to do the work ABC has been doing. People talk about the cool stuff other node teams are doing and I agree. I could be mistaken, but my understanding is that the other teams are freed up to do cool stuff by ABC doing the time-consuming maintenance work such as backports from core for them.

I agree ABC seems to be making mistakes and is too hard to work with. Your article above is full of excellent points. I think weakening ABC's position as you call for may be a good idea to get them to consider the arguments coming from the community and businesses. My problem is not seeing a better team offering to do the workload ABC has been doing.

Also, if there will be a split, I think it is best for BCH if one side of the split is weak and unimportant. I do not see ABC's side being weak in Nov.. So, getting a stronger BCHN before a fork seems bad for BCH. The anti-BCH attackers will tell you ABC is going to be weak (and is weak now). They will lie to you all to do maximum damage to BCH. They are very persuasive and many accounts on social media work for that goal.

$ 0.00
3 years ago

Super article

$ 0.00
3 years ago

fell free to fry me in the owen and bring some more interesting post.

$ 0.00
3 years ago

Indeed, really great and informative article thanks for this one

$ 0.00
3 years ago

Great article here is a link to learn comprehensively about Bitcoin Cash mining https://read.cash/@FJ/huge-profitability-will-be-realized-as-a-result-of-bitcoin-cash-mining-3646664d .

$ 0.00
User's avatar FJ
3 years ago

The inflation of currency value will be counterproductive and the chances of a backfiring is eminent

$ 0.00
3 years ago

"Bitcoin is supposed to be censorship-resistant worldwide electronic cash, to bring economic freedom to the world, and to free people from the economic control of corrupt and self-serving governments, not to be an investment vehicle for early adopters to get rich. In order to accomplish its goals, Bitcoin's rules need to be kept fair and economically consistent. We should not allow changes to Bitcoin Cash's economic policy that take from future users to enrich the present ones. If we follow this path, there likely won't be any future users to take from."

This is an implicit lie. Grasberg does not take from future users to reward present ones, the drift aspect actually does the opposite, taking from present miners to give to future miners, also decreasing the inflation rate, which is GOOD for users.

$ 0.00
3 years ago

From a perspective of fixed-value tokens, I'd agree with you. From the perspective of market-demand-driven token value I think jtoomim is probably right.

I mean, the coins we "save" by not emitting now, we can't be sure they'll actaully be worth something in 2139, right? But we can be fairly certain that if reduced supply increases price, current coin holders would benefit, and that people who abused EDA might be such coin holders.

$ 0.00
3 years ago

Bullshit. That still wouldnt be "robbing from future users to benefit present ones". You guys are just straight up lying.

$ 0.00
3 years ago

If you are right, I think Grasberg gives to the future as Mr Nester says. Assuming little future value to make the logic work is not persuasive to me.

$ 0.00
3 years ago

I think you may be right about this. I guess that would explain the down-votes, lol.

$ 0.00
3 years ago

Wow this article are great !

$ 0.00
3 years ago

Very Interesting article. More article about bitcoin cash please!

$ 0.00
3 years ago

that was a great effort and a good written article by you.

$ 0.00
3 years ago

toomin your a rat working with outside forces trying to destroy bch as a whole. you should understand business. and even 10 min block is rubbish. it should be much less example 30sec-1min.

let the coins run out in a few years and allow miners to earn fees. this is how bch can become real p2p. who is going to be around in 100+years to see this. if you die 2moro someone else will rewrite the code and do what they like. the amount of rubbish posted about this topic is insane. get laid. see a whore. your just looking for attention just like your whore of a mother. end point why fund this read.cash in 1st place. spend your bch on thing you want not encouraging this mad insane toomin.

bchabc is whats running and working now. if outside forces want to fund well let it happen. who cares where the money comes from. we all just want to get paid and earn cash. Bitcoin cash.

toomin you should stop this rubbish i believe you have been sent to disrupt the BCH camp. Now more are getting involved and you cant handle we can buy bch while your still not got any money. Dont think this is a get rich quick . i have been around since 2009. how old where you then? you should watch every move you make, say and do from now on mr toomin. we r watching you and if your lucky we may come and see you and your family.

all the best grow up work as team and stop claiming donations. give these to the people going with out food who are starving to death. and your talking about your thought on 11min block time. c'mon toomin do 1 min blocks at least this is better. your handler is some fud nsa who thinks this is still a cold war with ruskiz.

grow up and dont listen to toomiin or anyone on this matter.

mine earn and spend bch.

spread the word to the world

anyone you see or hear tell them Bitcoin Cash. send them to bitcoin.com, get more and more.

you are lucky to have options and ease of access to buy coins online these days.

you stupid americans. no brain cells between the lot of you. americans are some stupid people look it up, 27 in world maybe less.

$ 0.00
3 years ago

it should be much less example 30sec-1min.

I would love to get to very short block times while still maintaining decentralization. It's going to take a lot of work, though. I believe the first step should be getting ultrafast block propagation, and I think Blocktorrent+UDP will achieve that.

Once that's done, 1-2.5 min block times at scale (e.g. 1000+ tx/sec) should be be feasible, and we should start talking seriously about changing the block time.

After Blocktorrent, I think that the main area of promise is looking at using a DAG or braid instead of a chain in order to get rid of the incentive problems we currently have from orphan rates. I don't know if these ideas will pan out, but there's some promising research from Jute on 6 second block times:

https://github.com/Taek42/jute

...

you should watch every move you make, say and do from now on mr toomin. we r watching you and if your lucky we may come and see you and your family.

I started replying to your comment before I read all of it. I regret that now. I wish I had just downvoted and moved on. Oh well.

$ 0.01
3 years ago

I think we have a new hero in Bitcoin Cash .. Thanks for sharing, this is a huge job that requires time to breathe, from Venezuela, we send you hugs

$ 0.00
3 years ago

My guess is we'll look back, and this post will be what turned the ship back in the direction of decentralized P2P cash. Thank you jtoomin for your leadership and integrity.

$ 0.00
3 years ago

Awesome job explaining this

$ 0.00
3 years ago

Good article

$ 0.00
3 years ago

Thank you for the information dude!

$ 0.00
3 years ago

nice article this is so imformative.

$ 0.00
3 years ago

Wow,nice article,knew nothing about DAA Before now

$ 0.00
3 years ago

Great article nice to meet you

$ 0.00
3 years ago

Well my friend, I think this is an eye opener for me. Thanks alot.

$ 0.00
3 years ago

Nice article

$ 0.00
User's avatar Ify
3 years ago

great article!

$ 0.00
3 years ago

very informative article thanks

$ 0.00
3 years ago

Nice article...

$ 0.00
3 years ago

Indeed a great article

$ 0.00
3 years ago

This is really a great article. Found lots of amazing informations.

$ 0.00
3 years ago

wow great article dear realy its vary helpful to us

$ 0.00
3 years ago

It's a very helpful content. Thanks to the writer

$ 0.00
3 years ago

Great article sir .

$ 0.00
3 years ago

@jtoomim i really dont know much about nodes and market analysis.. but your detailed writeup has given me a real insight about the concept behind the crypto cycle and i really appreciate the fact that Bitcoin Cash has a bag of knowledge like you i feel a boost in my knowledge about crypto

$ 0.00
3 years ago

this is by far the most enlightening article i have read on bitcoin cash

$ 0.00
3 years ago

Sir applying to translate your article to Hindi.

$ 0.00
3 years ago