Like most of us in the Bitcoin Cash community, I want to see a fast and reliable P2P cash network that can scale globally. I haven’t been very vocal in the community but I’ve been observing it for some time. I have to admit that it can be quite entertaining to watch. Since the departure of Craig Wright, the BCH community seems to be aligned on the end goal for BCH but divisions remain in how to get there. This became very apparent during the Infrastructure Funding Plan (IFP) debate which proposed to fund infrastructure projects by directing 5% of the coinbase rewards over a 6 months period. Some opponents disagreed with the whole idea by calling the plan a tax on miners while others disputed how and who these funds should be allocated to. Under the threat of a new fork, Jiang Zhuoer and other key proponents for the IFP removed their support. A new split was prevented, the BCH community could take a deep breath.
Think You Escaped The Fork? Another One is Waiting Around The Corner
Updating the Difficulty Adjustment Algorithm (DAA) has been on the radar of the BCH community for a long time. Mark Lundeberg who designed the new DAA even wrote in his review of Grasberg (Amaury’s DAA proposal): “I'd given up hope on BCH ever getting a DAA and I'm pleasantly surprised that this seems to be happening”. Although Amaury’s announcement to update the DAA for the coming November fork could seem like a step forward for BCH, it turned into an outburst of indignation among several members of the community. Amaury’s announcement was quite unexpected as a few days before, the ABC team (Amaury Séchet and Antony Zegers) didn’t make any commitment that the new DAA would make it to the coming fork. At the forefront of the insurgence, Jonathan Toomim (independent BCH developer) who proposed his own implementation of the new DAA (ASERT). Although Amaury’s credited Jonathan in his Grasberg announcement, Jonathan was unsatisfied with the ABC team for not taking the time to review his DAA proposal. As for most wars, it’s often unclear who started it first but Amaury’s announcement was perceived by many in the community as an unacceptable escalation. At this stage, it was clear that the community reached a point of no return and that the two camps were at war, heading BCH toward a new fork.
ASERT VS Grasberg: The Smokescreen Hiding The Real Battlefield
In the days following the Grasberg announcement, Jonathan wrote a series of posts comparing ASERT and Grasberg that he published on r/btc and read.cash (post 1, post 2, post 3). The most contentious element of Amaury’s proposal is related to the historical drift correction of BCH coin emission schedule that Grasberg would correct. Amaury’s reasoning for correcting historical drift is that the DAA update will modify the coin emission schedule and as such, the genesis block is the only reference point that can be used. Other reference points would create the perception that this update will modify the coin emission policy, therefore, impacting the hard money property of BCH. To this assertion, Jonathan responded in his last article that the least arbitrary reference point to choose is the most recent (pre-fork) block which ASERT would do. Without getting into the technicalities of both arguments, it is apparent that the disagreement on this point is more of philosophical nature which makes it impossible for everybody to agree on the matter.
Jonathan’s comparison also discusses the impact on the user experience of correcting for historical drift. Indeed, under Grasberg confirmation times would be degraded by 19%-25% over the next 6.5 years. To this point, Amaury argued that it doesn’t matter as the current confirmation times aren’t satisfying anyway and that no use case would be impacted by this change. Although a case can be made that Amaury isn’t entirely correct on this point (since transfers to exchanges may be noticeably longer as exchanges require several confirmations), Amaury works toward making BCH the best P2P digital cash. From this point of view, it is true that the degradation in performance from Grasberg wouldn't have a significant difference in the user experience (Amaury aims at confirmation times below a few seconds).
From the perspective of an outsider to this community, these disagreements may seem of secondary importance and should certainly not justify a fork. The reality is that these disagreements aren’t at the core of the discord.
CTO VS Community: The Core of The Discord
One thing nobody can blame ABC for is that they’ve always been transparent about their roadmap. Executing on such a roadmap requires expertise, leadership, and discipline. This is even more true in the blockchain space where competing projects raise millions in funding. The competitive pressure doesn’t leave a lot of margin for error to the ABC team. Mistakes in feature prioritization or poor implementation choices can easily delay the execution of the roadmap by several months.
Since the IFP debacle, there has been a lot of criticism directed at Amaury for his authoritarian leadership style. This is no surprise as he defined himself as the “benevolent dictator”. His communication style is also not the most polished, to say the least. His frequent use of the word “fuck off” makes Amaury’s style quite singular. That said, whether people like his style or not, few will discount his technical expertise. According to Joannes Vermorel, CEO and tech auditor at Lokad, Amaury is in the category of the top CTOs you can almost never afford. Amaury is to BCH what Vitalik is to Ethereum or Dan is to EOS: a technical visionary who gets things done, a CTO that can lead a team to achieve his vision. Obviously Vitalik and Dan get more things done but they have access to a lot more resources than the ABC team does. That said access to funding is not Amaury only obstacle.
Within the BCH community, there is a strong expectation that everybody’s opinion should be heard and that every code contribution should be considered, reviewed, and improved. Feature implementation should be the result of a collaborative and iterative process that ends when everybody agrees with the finished product. Below are a few examples to illustrate this point:
"It's likely that BCHN would be a much better leading implementation than ABC was in terms of collaborativeness, since ABC is setting a very low bar in that respect. But what we really need is a decentralized system. We need to be able to agree what goes into the protocol even if we don't have a leading implementation. Only then will we be able to make group decisions in a fair manner, and to prevent developer centralization attacks against BCH." - Jonathan Toomim, Independent BCH Developer - Source
"Something like the DAA and the drift reparations should usually be the former type: this should be the kind of thing in which the cost of splitting would exceed the value that's at stake from the change itself. In these kinds of scenarios, it's more important that we agree on the decision than it is that the decision be the optimal one. " - Jonathan Toomim, Independent BCH Developer - Source
"Roadmaps should clearly specify whether something is a research project that will be formally proposed once more data are available, or whether something is expected to be implemented, and which everyone should have agreed to the principles of." - Jonathan Toomim, Independent BCH Developer - Source
"The stated goals of Bitcoin Cash Node include basing development on wide ecosystem input and deciding on consensus changes collaboratively. So instead of "Bitcoin Cash Node defines what Bitcoin Cash is", you should interpret the name as "Bitcoin Cash decides what Bitcoin Cash Node does". I think today's joint statement with so many non-BCHN developers is a great example of that." - BigBlockIfTrue, BCHN Developer - Source
"Objectives: [...] Demonstrate evidence-based, collaborative decision making on consensus changes." - BCHN Website - Source
I don’t think many would disagree with the benefits of collaborative processes for product development however the distinction to be made here, is that a part of the BCH community is advocating for this process to take place at the community level rather than the team level (such as ABC). This approach is obviously in direct conflict with the CTO-oriented model played by Amaury. It is also worth noting that this community-driven process also conflicts with the current Bitcoin Cash consensus model in which miners vote with their hashpower on which client implementation to support. In short, whoever owns the main client implementation gets to make the product decisions. There is no built-in process that enables the community to reach an enforceable consensus. As such, when Jonathan says “which everyone should have agreed to”, it is unclear who gets to make the decision on who would be part of the “everyone” and who wouldn’t be part of it. With scarce resources, it is also unreasonable to think that ABC has the bandwidth to consider all inputs from the community. Proponents of a Community-driven approach would like to see more community contributions to be pushed into production and consider ABC as a bottleneck to achieving this goal.
The real question that will be asked to miners on the November fork isn’t whether they support ASERT or Grasberg but rather if they want BCH product development to be CTO-driven or Community-driven. Interestingly there is at least one precedent on the matter among blockchain projects that I can think of. If we take the example of the ETH-ETC split, it is fair to say that the decision to intervene to stop the DAO hack was CTO-driven (Vitalik). This decision led to the split of the chain resulting in the creation of ETC which has adopted a community-driven culture for product development.
Is Amaury Cornered or a Game Theory Master?
I’d like to conclude my thoughts by reflecting on Amaury’s situation. Although it is impossible to gauge how representative of the overall BCH ecosystem his opponents are, it is clear that ABC has lost the battle on the social media front. Although social media channels tend to distort our perception of reality, it is undeniable that Amaury has lost some support within the community. Some of his opponents are even claiming that Amaury is ready to surrender or that ABC is already dead.
“There is no coming back from this for Bitcoin ABC as an organization. This is the end-of-life for Bitcoin ABC.” - Jonathan Toomim, August 4, 2020
But what if this scenario was intelligently orchestrated by Amaury?
Indeed, the main reason why Amaury couldn’t get the IFP passed is that mining pools were afraid that it would cause a split. As Jiang Zhuoer said: “No IFP! No Split!”. As the November fork may rhyme as “No IFP! Still a Split…”, it could present a window of opportunity for Amaury to reintroduce his IFP and give the miners two options:
An unfunded community-driven product, or
A funded CTO-driven product
By removing the fear from the miners to cause a split as a consequence of them supporting the IFP, Amaury would kill two birds with one stone:
Get funded
Assert his position as the CTO of Bitcoin Cash
Checkmate?
good article sir..