Ever since Bitcoin Cash was created, the need for a specification has been very present in the minds of the people who created it. This is why we took it upon ourselves to document every single change we made to the protocol.

It is possible the find the specification of OP_CHECKDATASIG here: https://www.bitcoincash.org/spec/op_checkdatasig.html

The documentation of the new cashaddr format: https://www.bitcoincash.org/spec/cashaddr.html

However, while we took great care to document any changes we made, one major problem remained: the existing state of affairs is poorly documented. The best effort on that front is, to my knowledge, the bitcoin.it wiki: https://en.bitcoin.it/wiki/Protocol_documentation

This leaves with a task way bigger than we have manpower for. While many asked for a specification, very few have risen to the task of making it happen. The current specifications have been almost exclusively written by Antony “Mengerian” Zegers, Shammah Chancellor, freetrader, Mark Lundeberg and myself. These are names that anyone familiar with the Bitcoin Cash community will recognize as major contributors and herein lies the issue: it is expected from a handful of people to not only design the protocol, but coordinate with the ecosystem, write the software for it, run tests, and write a specification for it, all with little funding and a lot of posturing from 3rd parties wanting to gain influence without providing the amount of work that would justify such influence.

Enter Josh Green and Bitcoin Verde. Josh has proposed himself and his team to write a specification for Bitcoin Cash. His company wrote the Bitcoin Cash node Bitcoin Verde, and he more than anyone else can attest to how important having a proper specification is, as it would have made his job tremendously easier.

The creation of a formal specification for Bitcoin Cash is great news! However, we need to keep in mind that a previous attempt at writing a formal specification occurred in the past, funded by nChain. Taking control of the specification, rather than contributing to preexisting efforts, is a logical move for an attacker wanting to take advantage of a poorly funded infrastructure. As Justin Bons stated, a poorly funded and maintained infrastructure is susceptible to capture.

In order to make sure no act of manipulation takes place, it is vitally important for the community to ensure that the right people are involved. People who have proven, not only by their words, but by their actions and achievements, their commitment to Bitcoin Cash and its goal: peer to peer cash for the world, enabled by cheap, fast and reliable transactions.

Josh Green is a good leader for this project. He has proven to be professional, and writing a node from scratch is an achievement that can hardly be understated. It demonstrates great commitment, outstanding professionalism and the capability to lead his team toward success even under very short timelines, in addition to a good familiarity with the details of the protocol.

But Josh’s involvement is not enough. For this project to be a success, it is imperative that he leverage the talent of other members of this community. With this in mind, I strongly suggest the following additions to the existing specification authoring team.

* Chris Pacia from BCHD, and who was instrumental in designing several features deployed on Bitcoin Cash, such as OP_CHECKDATASIG as well as several others in progress.

* Mark Lundeberg who, in addition to being one of the people who is already writing specifications for Bitcoin Cash, also designed and implemented several of its features.

Finally, the specification needs to be made in such a way that it is usable by all actors wanting to provide value to the Bitcoin Cash ecosystem. It must use a license compatible with MIT, which is currently the de facto standard in the ecosystem. But a license is not enough. It is also important that the specification doesn’t live in a walled garden. No matter what the license is, a malicious actor could create a de facto capture by requiring the use of non standard tools, for instance.

If this is done properly, this specification should live on the Bitcoin Verde documentation website, within bitcoincash.org specs as well as in any other place which desires to host it.

I support the effort to write good specifications for Bitcoin Cash. The points outlined above are provided because I believe they are instrumental in ensuring that the project provides genuine benefit to the Bitcoin Cash community. I will be following progress with interest, and hope this project has great success.