The topic of the current Bitcoin Cash Difficulty Adjustment Algorithm (DAA) is up again. It's both being discussed in terms of algorithm changes, but also in terms of the history of how we got the current DAA.
First, I want to say, moving forward with technical advancements is paramount. Anyone who is concerned about the DAA and has the skills to be working on it should be participating in writing requirements, specifications, simulations, and ultimately the C++ code to be included in Bitcoin ABC. The working group for these changes is here.
Given that the history of this change has come up repeatedly, I think the Bitcoin Cash Cryptocurrency Investor Network should have all perspectives available to them. So, I am writing here for a collective record and to inform people who are not reading Slack messages.
And, when reading this account, keep in mind that it is now three years later from the events being discussed, and and there is still no solution that is agreed upon, has a specification, and a working C++ implementation. We don't even have an accepted list of requirements.
At the time of the DAA, I was newly involved in the Bitcoin Cash project. I had some past history with Amaury, and was aware of his communication style from working with him on past open source projects. Part of the difficulties people have with him are due to English being a second language, the fact that he is French, and becoming impatient and frustrated with himself when he is he is struggling to convey his meaning in a way that can be understood. Attempting to bridge communication gaps was one of my considerations in choosing to get involved in Bitcoin-ABC. I had no prior experience working with any of the other developers involved in Bitcoin Cash protocol development to cause past history to taint current communication.
My perspective and experience in working with other Bitcoin Cash developers on the DAA is by no means fact. It is the truth insomuch as it is my experience, and my feelings - just as all the other statements about this history are also true feelings and experiences.
However, these feelings are not fact and it always takes two to tango. When I was still working on Bitcoin-ABC I saw an environment where mind reading dominated. Developers failing to practice egoless programming, allowing their feelings to be hurt. There was also a general lack of understanding around how criticism in code reviews come across to other humans. Good faith was generally never assumed. Nearly, every developer in this space, including myself, is guilty of one or more of these behaviors.
Now, regarding the DAA flaws. ABC was aware of the potential for resonances. I even came up with my own algorithm that was easy to implement, but it ultimately wasn't implemented. Amaury was even very amiable to it. However, it was after the release was already in flight -- it had taken too long to come up with an adjustment.
The reason the release needed to be done at the time it was, was to be ready for the S2X hardfork of Bitcoin Core. There would have been three major contenders for SHA256 hash, with major price changes between all of them. Miners would have been switching chains continuously, and result in even worse problems for the existing EDA on Bitcoin Cash.
However, other developers continue to say this:
Freetrader claims that Amaury could have chosen Tom Harding's algorithm and did not for some unspecified reason. From context, it is unclear if Freetrader thinks that Tom Harding's solution should have been implemented. However, other developers, within the context of three years, have continued to assert that Harding's DAA was not implemented due to Amaury's insistence on only using his own solutions. I don't believe that was his motivation. I was involved in the selection decision and signed off the choice.
And the fact that this is still being talked about, rather than acted upon by the people who are talking about it, is indicative of a real problem.
Amaury made the rational choice between alternatives. Getting a reasonable DAA out the door before things became even worse should have been a priority for everyone. Perfect is the enemy of good, and complicated solutions have more surface area for fatal errors. The DAA as it stands is extremely simple, but there is a lot of room for improvement.
For those not aware of the history, the Emergency Difficult Adjustment algorithm was performing terribly. The EDA was written by Amaury with input from other developers who did not want the original Bitcoin DAA changed at all; but it was not his preferred solution. Had Amaury listened to the consensus of developers at that time, the August 1st 2017 Bitcoin Cash hardfork event would have resulted in a blockchain that was dead-on-arrival.
The #1 reason we went for the EDA mechanism is that many actors were opposed to any change to the DAA at all, and EDA was the bare minimum possible change that could ensure the chain's survival in face of a hashrate drop at the fork point. Not because it is the best solution. Not because it even is a good solution, because it is what people were ready to accept. It is clear by now that more is required, and it would be a shame to not leverage all the great work that people working on alts have done. Some will call this copyright infringement, I on my side, call this science.
Amaury Sechet via Bitcoin-ML
It became apparent that the EDA would be a problem in August. There are an abundance of posts on the bitcoin-ml from Amaury about it, as well as others. Indeed, there was civil conversation there, initially, but no actual consensus on anything. Freetrader claims there was almost agreement on this issue. I don't know how he has any better mechanism for determining this than myself, or anyone else; which is to say no mechanism at all.
That being said, I would like to be proactive rather than reactive, so I worked on the problem to make sure we can deploy something if/when we think it is needed.
Most implementations are basing their mechanism on the block time, however, this data is extremely chaotic and can also be faked to some extent by miners. In the ideal world we want to estimate hashrate over several blocks and then use this estimation to recompute a new target. Because the input data is very noisy, we need to either do that over long timespan, but then we adapt poorly to violent hashrate swings, or quickly, in which case the difficulty output ends up being chaotic and may not be stable. Ideally, we'd come up with a solution that rely on individual block time as little as possible as this is the least stable data we have.
However, these discussions devolved quickly when, in mid October 2017, Amaury decided to start implementing a DAA himself. This first iteration was ultimately abandoned due to feedback from Neil Booth, and others. Neil Booth came into an ABC development chat - seemingly upset - to point out that the newly proposed DAA would be incredibly difficult for SPV wallets to implement. I explained to him that nobody was trying to break SPV wallets, and that we would do whatever is necessary to ensure that didn't happen. The situation was temporarily de-escalated.
Then, Tom Harding and Neil Booth both started working on simulations of various other algorithms. Amaury was also doing the same. Their repository is here, and was an effort I actively participated in. However, my feedback was repeatedly dismissed by both Tom and Neil. Tom Harding believed I was working for nChain and could not be trusted -- rather than looking at the content of what I was telling him.
If we almost had agreement then, why are debates about difficulty adjustment algorithms still ongoing now - 3 years later? I'm glad we haven't been stuck with the EDA for 3 years.
This kind communication only got worse from there. Both algorithms that were proposed had major flaws by my estimation. Neil Booth's algorithm was asymmetrical and thus unsuitable to the problem space. He persisted until he decided Tom Harding's algorithm was better some time later. Tom Harding was continually asked to show that his algorithm responded reasonably to selfish mining. Freetrader admits that Tom's response was: "I want Amaury to prove he doesn't beat his wife" -- these kind of remarks derailed all attempts at any productive collaboration. ABC developers did indeed review all these proposals, Antony Zegers even provided a detailed write up about Tom Harding's proposal.
Meanwhile, Peter Rizun was arguing publicly against changing the DAA at all. Claiming that leaving it in place would "cause a death spiral that would kill off BTC" (paraphrased). Assuming it were possible, that would have been absolutely disastrous for the entire cryptocurrency space. Tom Zander (the maintainer of Bitcoin Classic) was still advocating for a reverse-EDA, which would have not helped the situation involving S2x at all.
After the new DAA was incorporated into ABC, Neil and Tom went into various public chats, private chats, and direct messages, to claim Amaury was being rude, strong-headed, ignoring feedback, and ultimately implemented his solution because of his ego. Many people, without any other knowledge, and trusting these two developers, took what they said at face value.
However, this was not my experience when interacting with these three individuals in trying to develop a new DAA. These public allegations have become a running theme, over the last three years, with nobody seemingly remembering that it takes two people to have an argument. The ramifications on the progress of Bitcoin Cash have been substantial.
A well known friend of mine, and software engineer, told me privately something to the effect of, "Can't Amaury just merge someone else's solution so people will be stop complaining?" Network protocols are not about people's feelings, and merging poor solutions to placate people is not a good precedent to set. Since that time, despite the claims about Amaury, he has merged a lot of code from other people.
Given Freetrader's renewed interest in development processes, and evidence-based development. There's another aspect to consider when he says that we were near agreement at the time of the DAA being implemented.
How does he know this? How does he come to this conclusion? Who was involved in this agreement? Are we simply exchanging one set of people as decision makers for another? Do we implement solutions by voting? Who gets to vote? Who gets to propose things for a vote? What is the actual consensus mechanism that Freetrader wants to see?
There is some history that might shed light on to Freetrader's mechanism for development. He was participating in ABC up until December of 2017. He ultimately left shortly after Amaury went ahead with implementing CashAddr in Bitcoin ABC.
Freetrader wanted to throw out a public community survey to gauge support on this matter; tacitly expecting people to come to him. Amaury wanted to reach out and have direct communication with parties that had relevant experience to provide useful feedback. He ignored Freetrader's surveys in favor of the data he had already collected from direct contact with businesses in the space. Even one of the Copay developers preferred the CashAddr specification. Fixing the address format was an important change to make happen as soon as possible. Significant amounts of money was being lost by sending to the wrong addresses. I tried to on-board multiple friends and lost funds when they sent me a BTC address.
In fact, this issue should have been resolved by the time of the fork, and a suitable address format already implemented. The draft CashAddr specification was 7 months old at the time of the fork, and some kind of resolution should have happened on this issue. Would the BUIP vote sufficed at a community survey? Maybe, but BUIP037 was never even brought to a vote within BU.
People believed so staunchly that Bitcoin Cash would take the BTC ticker and name. They refused to do the work on necessary features to ensure the survival of Bitcoin Cash if their beliefs didn't work out - they perpetually failed to consider any alternative than their own visions; they failed to gauge that social consensus was not actually on their side.
Now, implementing another supported address format was totally within the scope of Bitcoin ABC. This was not a network consensus change and did not require anyone else to implement it. It could have remained unused by the rest of the ecosystem. The rest of the ecosystem could have coalesced around any other address specification. Amaury did not force it on anyone, and yet there are still people who believe that Amaury somehow made people implement this.
Nevertheless, shortly after CashAddr was incorporated into Bitcoin ABC, Freetrader disappeared from participating in ABC. He can speak for his own motivations, but it seemed that it was in regards to how the survey was disregarded. He is still doing community surveys. But neither surveys, nor their results, imply that there is broad community support for anything. How are people genuinely notified they need to participate? How does someone know people haven't participated more than once? Who collates the results? When community opinion conflicts technical requirements, who gets to make the final decision?
It ultimately amounts to a system were Freetrader would end up making the final decisions, and he would show his survey as evidence that his decisions had community support to dismiss critics. But this evidence isn't evidence of anything at all - just like BUIP votes from Bitcoin Unlimited are not representative of the businesses and user base of Bitcoin Cash.
Another complaint lodged by Freetrader is about making decisions using unpublished data: However, the data was circulated between individuals but never prepared for publication due to prioritization. Freetrader either had access to, or could have access to. If it was his priority, where was his write-up to formally publish it? There was a severe shortage of hands at this time to do everything necessary, a significant number of people complaining, and almost no volunteering to do any of the work.
When Bitcoin Cash finally came on the scene, there were already three forks of Bitcoind: Bitcoin Classic, Bitcoin XT, Bitcoin Unlimited. None of the lead developers of these codebases could get along, that is why they came to be. If these developers were capable of getting along in any meaningful way, there would never have been any need to fork Bitcoind multiple times. Amaury Séchet was not the source of their inability to collaborate - it clearly preceded him.
And again here we are, three years later from the events around the DAA and no solution that everyone agrees upon has been specified, coded, and released. We don't even have an accepted list of requirements.
From my perspective, Amaury's primary "sins" have been to:
Having the fearlessness to make decisions when others would not, and deal with the possible consequence of his client forking off.
Dismissing individuals who are more interested in debating solutions rather than solving problems.
To have little patience leading him to speak harshly to others he deems to be wasting his time.
To sometimes erroneously assume that some people are no longer worth working with.
And to generally be terrible at giving meaningful feedback on code reviews, instead expecting mind-reading, or attempting to use the Socratic method in lieu of giving clear constructive criticism. Attempting the Socratic method with someone who didn't sign up for your class is almost always seen as condescending.
Amaury has made fearless executive decisions on what to include, or not include, in Bitcoin ABC. And he has been short with people who wished for him to include something. However, nobody has ever been entitled to have their code incorporated into that code repository. People have always been free to run, or not run, the Bitcoin ABC software.
For whatever reasons, people have continued to do so. It is asserted that he has the power to force his changes on others, but who gives him that power? He only has the authority to merge code into Bitcoin ABC. Where does the public outcry over changes to Bitcoin ABC come from? If I make a Bitcoin Cash Node that has protocol changes that people do not want, would anyone care?
After three years of these disagreements, Freetrader has come back from his absence to work on Bitcoin Cash again. His new project exists primarily in opposition to Bitcoin ABC, rather than an effort to move the needle forward on P2P cash. The disagreement, that brought him back, was the infrastructure funding proposal.
Rather than assist with any existing project to come up with a palatable mechanism to do development and handle funding, he started his own project, and his own fundraising. Has this project helped in any way to build community consensus, or to further fragment it? Has progress been accelerated, or diminished?
The purpose of his project is an to attempt to implement a different decision making mechanism about what changes are, or are not, included in a bitcoin cash client. The Bitcoin Unlimited mechanism was insufficient, and the Bitcoin ABC mechanism was insufficient. It would seem that development decision have to be done the way freetrader wants for him to be willing to participate - and who could expect anything else?
But will he, and his compatriots, practice what they advocate and leave Automatic Replay Project in their client due to public dissent? Myself and many others do not want to see it removed. When freetrader becomes lead developer of Bitcoin Cash, will there be alternative ways to to make decisions? Or, will I have to use freetrader's way of making decisions?
And what has Freetrader's project accomplished so far? He's removed code for miner voting, and now proposing removing code for Automatic Replay Protection. What else will be removed, or left undone, based on "collective agreement" - whatever he deems is agreement, despite the fact that I, and many others, do not agree with the process?
If nobody has the ability to make decisions for their own project, how does anything get done? There will always be someone who does not want a change. It is human nature to resist change - change is dangerous.
Many have recently also stated that Bitcoin Cash is not Bitcoin ABC. It is as they say. Amaury cannot change Bitcoin Cash, he does not have the power to do so since the protocol does not belong to him. So, why are we having so many disagreements about what he chose to do on his software project with his time and energy? Why have any disagreements over what a project maintainer includes or does not include in their software - who cares? How can anyone claim that Bitcoin ABC has unilaterally changed anything about Bitcoin Cash?
Someone always has to make the decision to take the first step in building something. What we have right now is decentralized development. WE are free to do whatever we want and try to get people to run our updates. We are free to deal with the consequences of our software potentially not being compatible with anyone else's.
At what point will we leave the pettiness, over who gets to be in charge, behind and actually work to make meaningful products that we can show the outside world - products that will make people want to use Bitcoin Cash?
BCH 👍👍