The majority implementation crown is exceptionally heavy. I don't want it.

I do want network diversity.
I do want redundancy.
I do want a backup plan.

Preface

The lessons learned from Bitcoin Core and Blockstream will be forever remembered by the Bitcoin Cash community, and this community is proud to have multiple implementations.

Despite having 5+ node implementations, why was the entire network staggered last year due to a bug that existed in only a single implementation?

The answer isn't that node was of poor quality or that our network is only running one node implementation; in fact, neither of these things are true. The answer is that miners are only running one node implementation.

Bitcoin ABC is the only mining implementation

Bitcoin mining is a high-competition, low margin, risk-intolerant business.

During the infrastructure funding debate, we took extra care to understand the perspective of the miners.

When we asked why miners considered Bitcoin ABC the de facto mining implementation, we were told three reasons:

1. ABC's reputation for great quality

2. Limited alternatives willing to support mining/pool features

3. Homogeneous network decreases block orphan risk

Distilling this, miners are running Bitcoin ABC because of its reputation, running a single implementation is less risky for them, and there aren't alternatives that they trust.

Reputation

Objectively, Bitcoin ABC's reputation is fantastic. Not only is ABC producing stable, high-quality code, they are also innovating new features and providing a path for other implementations to follow. This is not an easy task, and they've been doing a great job.

Bitcoin ABC does great quality work. I agree with this.

Limited alternatives

I cannot speak for why Bitcoin Unlimited was not considered a practical alternative to Bitcoin ABC. However, all 5+ implementations should strive to be viable mining alternatives. Being viable means producing quality work; it also means reasonably obliging miners and taking their requests and concerns seriously. I encourage the minor implementations to start focusing more on this.

In line with that, I announced that Bitcoin Verde will be taking a heavy focus on becoming a viable mining node alternative.

Additionally, BCHD, Bitcoin Unlimited, Bitcoin Verde, and Flowee the Hub have been collaborating in the Bitcoin Verde Telegram about a minority node testnet for mining.

Improvement on this is on its way.

A single implementation is less risky

For a miner that is constantly battling limited margins, an orphaned block is very expensive. It's why creating 32MB blocks isn't a trivial debate, and why people saw benefit in CTOR/XThinner: there is risk with propagating blocks, and poor block propagation is an important concern.

Orphaned blocks can happen organically. They can also happen out of malice intent, or because of a disagreement in validation rules--even if that disagreement is unintentional. It is this latter cause that miners see a benefit of a homogenized node ecosystem for mining. It's sound logic. It's near-impossible to have a disagreement in validation rules if almost all of the miners are running exactly the same software.

However, it is not the homogenized ecosystem itself that miners want. What they actually want is increased profitability by minimizing the risk of their block being orphaned.

Reducing risk for miners

In the past, some adventurous mining pools have attempted to mine with minor implementations, however they were burned by invalid blocks that were then orphaned.

This risk is completely avoidable without resorting to a homogenized mining ecosystem.

To remove this counter-incentive to node diversity, we will be creating a block template validation service. This open-sourced service will alert miners when the template they are attempting to mine is incompatible with other implementations, and can be ran themselves or by a 3rd party.

The block template validation system removes the risk associated with miners running different implementations. Furthermore, with this alert system, miners will be able to prune the transactions that create network incompatibilities or choose to completely switch to a different template.

This service doesn't just benefit minority implementations, it also benefits miners, developers, and the live network as a whole. By checking the validation of the template across the entire network's set of nodes:

• miners can avoid accidentally splitting the network

• miners greatly reduce risk of producing incompatible blocks, reducing orphans

• developers can be made aware of incompatibilities between the implementations, which would be otherwise masked by the invalid block not propagating

• giving the miners greater freedom of choice in their node implementation

In line with how we said we'll fund development, we've created a GitHub issue to fund the prioritization of this feature. This issue outlines exactly what we're building, why we're building it, for whom it is for, and how long we think it will take.

We are offering transparency and accountability in hopes to break down some of the donation barriers that Bitcoin.com has rightfully called out. We hope this transparency helps inspire other would-be donators, so that features can be supported individually--appealing to the free market to represent demand, and avoid relying on an unaccountable slush fund.

We believe this service will become standard practice across all majority mining organizations, and strongly encourage recommendation from miners and the community for how to improve this idea.