How NOT to Run a Community Project

I've been paying attention to the Bitcoin Cash ecosystem lately, and how development is going. People have legitimate concerns about the usability of Bitcoin Cash, and the future of it as a technology. For a while, there have been many issues plaguing Bitcoin Cash and preventing it from getting any potential adoption in the future, and I'm making this post because the direction things are going in are extremely concerning not only to me, but also others in this community. For anyone who has been up to date with BCH, you will know that we recently had a DAA meeting, where developers discussed potential solutions to Bitcoin Cash's flawed DAA. The current DAA is causing issues with oscillation, and discouraging "loyal" mining strategies, while encouraging those of switch mining, causing inconsistencies in hashrate, significantly degrading user experience, potentially deterring new users from using Bitcoin Cash.

With the last DAA meeting, it seemed like everybody was in consensus about the DAA being changed, and wanted to discuss potential solutions with the objective of reaching an agreement. I, along with many other saw this as a positive and thought that ABC was willing to compromise with others towards reaching a solution. After all, that's what Bitcoin Cash is all about. ABC and others have had disagreements in the past, but maybe now they have learned that the point of a protocol having multiple node implementations is so one party cannot have a hostile takeover of development. After all, even those who support Bitcoin ABC believe this to be the case. Little did I know, I was wrong to make such an assumption. Not long after, another read.cash article gets published where Bitcoin ABC says that they are going to go forward with a new DAA, which wasn't even proposed beforehand to other node implementations and developers. Their reasoning for this?

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.

With this statement in mind, it makes it look like ABC wanted to reach a consensus and a resolution, and were "moving forward with Grasberg" in good-faith. This evidently isn't the case, and it is obvious when you see the hypocrisy in this style of leadership because:

• ABC is making it seem like it's important for node implementations to have time to review code and test it, making sure there aren't any issues with it before the feature freeze date

• ABC feels as if the proposals given now don't give "adequate time" for testing and simulation for said feature freeze date

• They're putting out their own DAA, of which, there aren't any officially published results by them on their website during a time in which by their own standards "which does not leave [other node implementations] with sufficient time to review adequately, simulate and test, and get feedback addressed before the feature freeze on August 15th", and then have the audacity to claim that they "[are] is inviting other parties to reproduce the results"

ABC didn't propose their solution. They said they were "going forward with it". They refused to acknowledge that there actually were other proposals which were more plausible for the November upgrade even though results had already been taken, were reproducible, and there was code available to them to assess. Bitcoin developer jtoomim had come up with a recent proposal for adding ASERT as the new DAA, which got a lot of community support, but didn't get acknowledged by ABC because he didn't "hand in a formal proposal in ABC's code", despite the fact that ABC could have copied the code, or at the very least acknowledged Toomim's proposal and request/remind him to give it in. I think this shows their true intentions.

Either way, I made this article to try and remind people that this isn't what Bitcoin Cash is about. The entire point of having several node implementations is for developers of said implementations to cooperate and reach a consensus on how to solve current issues with Bitcoin Cash, and improve it's usability as peer to peer electronic cash. I encourage other users and miners to ask themselves these questions:

• Do I want to run a node implementation that is unwilling to cooperate with others, and force their code, while implicitly threatening a split if they're completely on-board with it?

• Do I want to run a node implementation that intentionally makes it hard to cooperate and reach consensus?

• Does this style of leadership look familiar/has it happened in the past?

• In the future, when this node implementation gets full power over development, are they going to do what is in my best interest as a miner/user?

• Even if this node implementation does manage to cooperate this one time, is it worth still running it, despite having a track record of trying to force changes on the community, and are they going to continue being cooperative in the future?

I think it's important to ask yourself these questions because they can make or break Bitcoin Cash as we know it right now. If you as a miner/user can see the route that ABC is taking, I encourage you to switch over to another node implementation that shows willingness to cooperate. For now, I've switched my interests and support over to another project because it seems like ABC is fully in charge (in terms of hashpower and exchange support), and that makes it unappealing to support Bitcoin Cash at this moment. That's all I want to say for now. If anything changes in the future, or if ABC is no longer a popular implementation, I will change my mind, and come back here to support Bitcoin Cash as a community member. For now, I'm supporting Monero, but I'll still be active on the r/btc subreddit.