Join 100,637 users already on

Multiple Implementations and Cooperation in Bitcoin Cash

8 120
Avatar for Bitcoin_ABC
Written by
This user is who they claim to be.
We have manually verified this user via some other channel.
2 years ago
Topics: Bitcoin Cash

Bitcoin ABC develops the leading full node software for Bitcoin Cash, which is used to produce more than 95% of all BCH blocks ever. As such, we sometimes are asked our position on having multiple full node software implementations in the Bitcoin Cash ecosystem.

Bitcoin ABC very much welcomes new developers and full node implementations to Bitcoin Cash. We would like to coordinate and cooperate in an open and collaborative process. Multiple BCH full node implementations is ultimately good for Bitcoin Cash.

The Major Proponent

In fact, Bitcoin ABC has been the major proponent of Bitcoin Cash’s multiple implementations model.

  • Bitcoin ABC chose a name that purposefully differentiates itself from Bitcoin Cash. This is important to separate one particular implementation from the protocol as a whole. It required more work but it helped create an environment where other nodes can thrive.

  • Bitcoin ABC participated in a meeting in London with other implementations soon after the 2017 fork to ensure that we can have a common roadmap to work towards. 

  • Bitcoin ABC participates in regular developer meetings inclusive of other full node implementations so that matters of consensus and other policies can be agreed upon. 

  • Bitcoin ABC has created many ad hoc workgroups on various topics to facilitate coordination between different developers and teams.

  • Bitcoin ABC, until recently, was the primary team writing Bitcoin Cash specifications for the longest time - until the recent formal specification effort, which we are happy to see moving forward.

Bitcoin ABC has taken many steps to ensure that Bitcoin Cash can accommodate multiple, thriving full node implementations.

“I can say that ABC has helped out BCHD whenever we had questions or were working on protocol upgrades. The experience with the ABC team in this regard has been excellent and there is no doubt they value the work done by the BCHD developers.” - Josh Ellithorpe #

Competition or Cooperation?

It is important however to understand the proper roles of competition and cooperation with respect to full node implementations. 

Should Bitcoin Cash full node projects engage in some kind of ruthless cutthroat competition? If yes, then the steps Bitcoin ABC has taken, noted above, would be irrational. You would expect Bitcoin ABC to instead attempt to crush the competition.

The reality is that BCH full node implementations must cooperate on network policies and consensus rules.

Competition best happens between chains, not within.

Network Predictability is Good

Take the example of zero-conf transactions. The term “zero-conf” or “0-conf”, refers to transactions that have yet to be included in a block, i.e., have zero confirmations so far.  Zero-conf transactions can be subject to some risks, such as double-spending and other attacks, if network policies across all, or almost all, miners are not in sync.

If there is intra-network competition, meaning ruthless cutthroat competition among BCH implementations, then it can lead to inconsistent network policies. These inconsistent policies would result in the destruction of value for all users, as hostile actors leveraged our disagreements to attack us, particularly through double-spend attempts made possible by our inconsistencies.

Consistent network policies also increase miner efficiency and lower the miners’ risk of falling out of consensus.

Network predictability is good, and that is achieved through intra-network cooperation. Not competition.

If we can agree on intra-network cooperation, then no winners need be declared, and there is room for multiple implementations in a non-zero-sum game. No winner means everyone wins.

The Need for a Winner

If however there has to be intra-network competition, then there has to be a winner. The end result is further centralization of the network in the hands of the leading implementation.

The need to identify a winner means the competing implementations need to spend time and other resources on an internecine struggle that benefits no one but those who seek to capture Bitcoin Cash or hamper its growth.

The constant drain on resources from such an ongoing fight constitutes a net negative for BCH and reduces the resources available for it to compete with other coins. 

Multiple implementations is great. It is only the idea that these implementations must compete at the protocol and policy level that is harmful to the BCH ecosystem as a whole.

Two Different Ideas

It is critical to separate two ideas here that sound similar but indeed are quite different.

  1. Multiple Bitcoin Cash implementations are good.

  2. Bitcoin Cash implementations must fight to see who wins.

We can all support no. 1. It is inherently beneficial for Bitcoin Cash.

No. 2, however, leads to a struggle to see who will control the protocol. This is an inherently destructive process. We spend time fighting each other instead of building Bitcoin Cash so we can compete with other coins and flippen Bitcoin Core BTC. 

Bitcoin ABC supports no.1. We oppose no. 2.

Until we gain clarity on this, BCH will remain stuck in limbos, not being able to execute on its roadmap in a way that is compatible with its ambitions of becoming global money — possibly becoming irrelevant in the process or simply losing years of adoption.

The Roadmap

Bitcoin Cash is about achieving the Bitcoin Cash roadmap, which most major BCH players participated in creating. We want to create P2P electronic cash to serve billions of daily users. We have a plan to make this happen.

We must execute on this plan. Debating it endlessly will not get us there.  Debate may be intellectually stimulating, but at the end of the day nothing gets done unless we stop debating and start working. This does not mean there should be no debate, it simply means that we most focus on making forward progress.

Disagree with the roadmap if you please.  If you think another plan is better, then please execute it on its own coin.

If you think feature-rich smart contracts are the thing, for instance, then join the ETH community. BCH made the choice to have more limited smart contract features so that it can have an architecture that scales better.

If you think that BCH needs to experiment with governance mechanisms by making decisions via X or Y, then try Tezos or a similar coin. BCH is about P2P electronic cash. It already has a roadmap.

There is nothing wrong with any of these ideas. In fact, they are  important ideas that demand rigorous exploration. But they are not part of Bitcoin Cash. The purpose of BCH is to become P2P electronic cash by creating a scalable blockchain with fast confirmation times using pre-consensus techniques.

If we want to spend more time debating matters which are already settled; if we want to talk about doing rather than just doing; if we want to foment one rebellion after another; then Bitcoin Cash will continue in its current limbo. Other coins will keep moving forward while we lag behind. Someone else will flippen BTC. The Bitcoin Cash project will fail.

We must execute on the Bitcoin Cash roadmap now and without further delay.

Constant Improvement

Bitcoin ABC aims to constantly improve. We know some people want to make this competitive. We don't see it that way. We just aim to do better today than we did yesterday in the quest for achieving our vision and realizing our values.

That said, Bitcoin ABC is the best implementation available right now, and miners have been choosing it. This is why it is important that ABC be funded now. This is why we are inviting those who want to scale Bitcoin Cash to billions of daily users to donate to our fundraiser at

Ideally, there will be more production-ready implementations in the future. 

ABC is focused on building the best software it can, providing value to BCH businesses and users, and on advancing the roadmap. We are happy to cooperate with other node implementations in advancing these goals.

We have big challenges ahead to gain mainstream adoption, and minimal resources to focus on them.

Let’s all move forward with an open and collaborative approach to growing Bitcoin Cash.

Join Us

Join the Bitcoin ABC team in building censorship-resistant P2P electronic cash for billions of daily users and realizing the vision that is Bitcoin Cash!

Visit to find our business plan, budget, delivery timeline, funding options and feedback mechanisms.

We can only do this together.

Got questions? Ask us below.

Stay Informed

Sign up here to get email updates on Bitcoin ABC.

Other Articles in The Building Series

Read the Fundraising Series

Start here to read the 15 articles in the Fundraising Series.

$ 0.06
$ 0.05 from @Koush
$ 0.01 from @Omar
Avatar for Bitcoin_ABC
Written by
This user is who they claim to be.
We have manually verified this user via some other channel.
2 years ago
Topics: Bitcoin Cash
Enjoyed this article?  Earn Bitcoin Cash by sharing it! Explain
...and you will also help the author collect more tips.


This article includes the assumption that the ABC Roadmap is the only way to go. So, we all must cooperate to follow the ABC lead. This attitude is what has helped make the current controversy significant. I love the roadmap and ABC, but, I suggest you add a mechanism for proposing changes to the Roadmap and the strategy for implementing it. An effort to show willingness to consider the different opinions of others is missing from this article and much of the ABC writings. I would guess there is some willingness to hear other ideas, that willingness is just not translating into a clear statement that such opportunities are available. I may not have stated this as clearly as I had hoped, but, I think people will get the gist of it.

$ 0.10
2 years ago

Thanks for sharing your thoughts.

The roadmap is not the ABC roadmap, it is the Bitcoin Cash roadmap. It was generated from a meeting where multiple full node implementation teams/developers participated, and that was open to all of them.

We don't have the resources to build out the current roadmap. So I fail to see the sense in spending scarce resources on more proposals and debating. The roadmap is set, and our job by common agreement is to execute it.

We need the resources to do that. More information is available at -George

$ 0.00
User's avatar Bitcoin_ABC
This user is who they claim to be.
We have manually verified this user via some other channel.
2 years ago

Thanks for the clarification. I do wish we did not need to waste time/resources considering the opinions/desires of the community. Sadly, I think failing to do so on the IFP issue has led to a dangerous situation for BCH. I hope I am mistaken and all goes well with the addition of the BCHN team's efforts. I hope they can be cooperative influences rather than destructive and competitive. I am for an IFP, but, I think forcing one through without more community support is risky. I hope all goes well and I am just over-worrying as I tend to do.

$ 0.00
2 years ago

The community was listened to in the creation of the roadmap.

This is a two-way street. We can't give people everything they want and do it for free also.

Ideas for a better IFP are welcome. Do keep in mind that funds and developer time are not available in abundance to develop anything more than a very simple IFP mechanism at this time.

Thanks again for sharing your thoughts. -George

$ 0.00
User's avatar Bitcoin_ABC
This user is who they claim to be.
We have manually verified this user via some other channel.
2 years ago

I do appreciate that there was listening in the past. I also realize anti-BCH agents are common, vocal and will try to make it seem like the "community" wants bad things for BCH). Like fooling the community into thinking we do not want to set up an automated system for miners to be able to donate to developers.

As for a future IFP-like automated system (I would tend not to call it an IFP or, especially "the IFP" due to the current vilification of the term) I would look for a way to gather 100% BCH miner support for a new implementation. Because BTC miners see it as an indirect tax or difficulty increase, I think BTC miners are a huge (unannounced) part of the anti-IFP movement. Are there enough BCH-miners who would be willing to donate (say 5% from block rewards) to do all the BCH mining? I wrote a couple articles looking for that answer and never really heard anyone say they thought there were enough BCH miners who would be willing to agree to it. If you could get that aspect worked out, BTC miners would probably still end up paying for most of it, but, the donations would be 100% voluntary, in theory. Miners could still switch back and forth, but, the system would have been voluntarily set up.

You will never find a way to make the anti-BCH agents happy, but, some of their complaints were fair points that attracted real community support. Even if pool operators have a lot of their own hash, it needs to be the miners who agree to a plan. If possible, look for an automated way to determine the distribution of funds. Maybe metrics like 90% to the team whose software is used by the most miner hash? You don't want developers determining which developers get the money unless it is a committee that has fair representation of the other node projects. If the whole proposal came from the 100% of BCH miners, that might be ideal. A way to have the system modified will be needed in case of gaming the metric. Maybe have a "BCH miners association" or something able to propose changes? Organizing miners has anti-decentralization tendencies even if it is already a thing we just pretend does not exist, so, might want to avoid supporting that idea?

Duration should be clearly stated. Maybe something like 7% for 16 months and then minus 1% every 12 months there after until it reaches it's minimum of 0.5%?. Maybe a cap of X USD value per month or per block in case of massive price rise? I would look through the anti-IFP articles and find easy to address concerns even if baseless. Things like an "unnamed HK Corp" should be easy to fix. An automated payout to developers would seem like the way to go anyway. I can come up with more tweaks if you are stumped by how to solve any of the anti-IFP arguments. Many of them are just false-logic attacks (social engineering) just made to seem logical when not considered too seriously.

EDIT: to keep protocol work minimized, maybe put the things like % and cap and distribution outside the protocol and set up the system inside the protocol so it need not be messed with in the future.

Edit 2: When I say 100% BCH miner support, I do not mean miner voting on chain as that can be gamed by BTC miners. I just mean something like a letter of agreement signed off on by enough hash to mine BCH fully.

Edit 3: I do not mean to say ABC should spend too much their time on getting this new system figured out. It would be great if miners did it. Maybe a kickstarter to fund the development of an automated-funding proposal, lol.

Edit 4: I do not need any detailed response to these ideas. I am just throwing out stuff hoping it can help. I appreciate you listening at all and really appreciate all the other stuff you have been doing to help with funding and outreach for BCH.

$ 0.00
2 years ago

Thanks for your further thoughts, definitely appreciate this! I will think more on it. -George

$ 0.05
User's avatar Bitcoin_ABC
This user is who they claim to be.
We have manually verified this user via some other channel.
2 years ago

the BMP project solves all of those governance questions

$ 0.00
2 years ago

Interesting. I am leery of organizing miners as I think the original theory was decentralized miner actions. Centralized governance is something I consider scary and dangerous for a decentralized crypto. I do want to be able to hear their opinions as you have seen in my other writings. It seems dangerous to organize miners or developers too much. It is all a sliding scale and perfect decentralization is not needed for censorship resistance.

$ 0.00
2 years ago