The following is a personal opinion / suggestion. I am explicitly not speaking for others in Bitcoin Cash Node (BCHN) here.
In recent weeks and days there has been intense activity around evaluating candidates for a new difficulty algorithm in BCH.
One such algorithm is "ASERT", about which Jonathan Toomim wrote an article and which is being implemented by some developers.
Another is "Grasberg", which Bitcoin ABC announced on July 23 and declared that they would be "moving forward with it".
This declaration has obviously caused some anxiety in the community as the Bitcoin Cash ecosystem must sooner or later choose one of these algorithms if it is to avoid some kind of split.
Failing to settle on a clear choice would result in either
not choosing a new algorithm for November
two or more teams "moving forward" with different solutions
My strong hope is that both these outcomes can be avoided. The first one would lead to continued poor block confirmation times and bad user experiences on BCH, kicking the problem down the road until some unspecified future time. The second one has the clear potential for a split, which would again be very detrimental to BCH.
Let me be clear: I don't think the Bitcoin Cash ecosystem is well served at all by being pressured to pick the first "available" solution to which one person or team commits itself. This has been tried before and it's why today we have a need to fix the DAA. 🤷
To avoid a recurrence, I want to propose a plan on how to settle on a clear, better informed choice.
This won't take all that much effort, but it will save tremendous costs and allow scarce development resources to be channeled to more productive things than implementing two or more algorithms in every software that validates difficulty. If the ecosystem does not "get its act together" and express what it wants to happen, then those really using Bitcoin Cash have to make plans that cover several outcomes, at greater cost to themselves and their customers.
The good news is there is still time to create a good outcome.
Suggestion for a plan
Step 1: Collect proposals until feature freeze on August 15
Right now, both ASERT and Grasberg are still in the review, testing and specification processes.
15 August 2020 is the so-called "feature freeze" date by which proposed upgrades to BCH should be submitted as specifications accompanied by reference implementations (i.e. code).
The ecosystem should afford all participants the chance to submit their candidate solutions by that date. It is up to entrants to supply their proposals with as much information as possible to allow others to evaluate and be convinced of the proposal's merits.
Since the DAA problem is urgent, unless some big difficulties are found in the current crop of candidates, I would not recommend that the August 15 deadline be extended. This is because much work still has to be done by many people once a choice is made.
Step 2: Review proposals, choose and make your choice known
After August 15, there would be a brief (but not too brief) period where stakeholders review the submitted solutions and then make their voices heard about which one they prefer.
Voting would be on technical solutions, and NOT about particular node clients.
Miners / pool should express their opinions on chain. They can freely change their voting (signal) until some cut-off date when their votes on chain -- and those of other stakeholder signaling on or off chain -- are counted up.
I would suggest that the entire voting period could take 2 weeks -- from August 15 until the end of August -- which should give deciders enough time to consider and express a choice.
Businesses making use of BCH would signal whichever way they usually present similar opinions. For example, via company website, blog posts or verifiable statements from company officers or spokespersons. Main point: send a clear signal to everyone.
Individual holders who wish to demonstrate their opinion could sign statements like "I prefer algorithm X" with some verifiable amount held.
No central authority is needed - we have a decentralized blockchain on which anyone can write. We have cryptographic signatures to give reasonable confidence that a certain party wrote something.
Nobody should feel obliged to justify their stated preference when they express it. Any feedback might however help those who proposed the solutions to do better in future.
Awareness of the process can be spread via the usual media (news sites, social platforms).
Step 3: Collecting the results
This isn't rocket science.
Several people can work together to speed the process up.
They would collect results in a shared public resource that cites the appropriate source references along the listed opinions and counts up the votes for each proposed solution.
A few days (a week at most) should be enough for this, esp. if some planning and coordination is initiated ahead of time.
Step 4: Further actions based on the results
If a clear favorite emerges from the data, then it is "congratulations to BCH community for choosing new algorithm!" and the projects that need to implement can now get on with their job. That's what the time between August and November (realistically, up to about end of October) is for - to implement the upcoming changes expected at the freeze date.
There will still be a lot to do before November to get the new algorithm into all the software that needs to be modified (nodes, SPV wallets, other libraries). But if there is a clear signal, that work has just become a lot simpler.
What if there is essentially a tie between the contending algorithms?
I will hazard the opinion that this is unlikely, as most realize that it would be a more difficult path to resolve.
Essentially, if it does happen, then it boils down to BCH miners deciding this (no, this doesn't have to result in a split - they can resolve it before November).
It's essentially up to the miners what that process will look like.
I'm not a miner, so again this is only my opinion. I'd be strongly in favor of some kind of on chain miner voting to settle things before November.
Why? Firstly, in order that the rest of the BCH ecosystem can verify what happens and secondly, that the wider cryptocurrency community can see that BCH miners value their coin and take an active interest in its health.
There are multiple options in which on-chain voting by miner can be done:
coinbase "signs" like
/aserti3-2d/or/Grasberg/or/noDAAchange/voting bits if they can agree on which bit refers to which proposal
BMP (could be a good first real use of this technology)
Again, a situation where miners need to make the decision situation would only be needed if no clear preferred solution has emerged from the previous consultation period. Otherwise this complexity and uncertainty can be avoided.
I believe this also means that the earlier the miners get involved with making their opinions heard, the better for the whole process. They are the deciders of last resort on technical questions whether they like it or not - through running the software that implements whatever choices are made available, they determine the chain's rules.
If there is no clear outcome by end of August, then until the mining preferences have further crystallized through on-chain signalling, software teams could take precautionary steps to protect their users regardless of the outcome in November.
Full node developers could construct software releases which implement two algorithms and let their users select the active one through a software parameter. Non-mining users of full node software could in this way easily switch to whatever miners decide, hopefully ahead of the upgrade.
If miners do well and narrow the choice down before November, software teams can easily remove the algorithmic capabilities that are no longer needed ahead of the upgrade and we all enjoy a smooth upgrade.
What if there is a vocal minority that does not accept the ecosystem's choice?
This is the case where there is a clear, but not overwhelming, favorite solution (e.g. 65-70% supported) but a vocal minority (of 25-30%) announces that it will not honor the results.
I believe it boils down to how much hashrate actually backs that minority, which may be a different figure and vary in the days leading up to November.
Thus, while it is essentially out of the hands of most Bitcoin Cash users, it is still in the hands of mining pools to affect the course of such a faction and to make the odds of success of an attempted split low.
One thing to remember is that is it is fairly well established that in the event of a split, the minority hashrate chain does not keep the name and symbol of the currency from which it broke off. Any minority would have to take this into careful consideration when thinking about whether it is worth it to them to depart from Bitcoin Cash.
I do not believe big BCH miners are incentivized to split Bitcoin Cash, nor are they incentivized to pick a worse solution if given the choice. After all, it is important to all users, including the mining operations, that there is stability not only in the performance of the difficulty algorithm, but also the reliability of the chain and currency to businesses who want to build on a stable Bitcoin Cash.
Lead image: Photo by patricia serna on Unsplash
But we are not in boxing rihg, let's agree, and that would be all choosing one of both algorithms, which would be the one with the highest speed and lowest costs, for the participants. that at the end the miners align themselves according to their interests.