A process towards acceptance of Bitcoin Cash Improvement Proposals

In Bitcoin Cash we have started on the road towards a process of including network changes into our ecosystem. This process has, as its most visible component, the proposal. We named this a CHIP.

Outside of the CHIP there has not been written a process of how this chip would magically manage to get activated, and this is causing confusion in the marketplace.
It is time to start writing down a process.


The first goal is to learn from past mistakes, BCH has failed to be properly managed too many times and while it would be easy to point at some villain, there are lessons to be learned that we need to hear.

The most important lesson is that a project like BCH can not be held in the hands of one or even a few leaders. This always fails.

The second most important lesson is that coordination between self-elected proponents has repeatedly given massive results. People that think likewise and join forces to push for a change, or indeed against a change, have managed to succeed in doing so. Lesson learned: coordination and collaboration works.

After that fluffy goal lets get a little more specific.

Changes made from the successful chain we have today should only happen if the majority of the participants benefit from such a change.

This goal needs clarification that the participants of Bitcoin Cash are not limited to just software developers, or miners or even companies. The reason we called our movement “Network discussions” is because our goal is to include the entire network of Bitcoin Cash.

Method considerations

There are two core lessons to consider when considering a method.

  1. any sufficiently detailed method moves the balance from well meaning volunteers to professional politicians. The financial system itself is a great example of this, but the law in most countries is as well.

  2. As the Austrian economics say: less rules is better. They specifically say this about government, where the market is better suited than government.
    The same concept applies on many levels. Take Peopleware, a 1987 book on the social side of software development by Tom DeMarco and Tim Lister.
    The best manager is one that actively removes obstacles from the path of the worker.

Learning these lessons will give us a method of activating changes on the network that is based on people. Allowing people that have the incentive to put the work in to actually make a change is very much in line with what Satoshi started with the balance he put in the core of the Bitcoin whitepaper. That means that it is cheaper to work in favor of the system than to go against it.


We have no leaders.

It is so easy for a leader to have followers and gain power. Power attracts the wrong people and rejects the people we actually want to participate. No leaders.

Nobody gets to define “the rules”.

People love rules, it makes interactions easier. Unfortunately rules also restrict.
So because we are talking about people that work together in order to increase the value of the network, we simply say that there can not be a rule which is absolute. Any rule can be broken in the right situation. People will just have to respect each other. Interactions don’t follow rules, instead the core here is people working together.

Participants in the “Bitcoin Cash Network Discussions” facilitate.

As proposals for changes are made they need to be tended to as they grow from an idea in a chat room to something that is implemented in code and accepted by the network.

There are a lot of steps, there is a lot of talking and writing and naturally bridging cultures. We can not expect a brilliant researcher to do this, we can’t expect the business owner to listen to the rambling of a techy.

Facilitation is deliberately vague. This is people working together to create value and the best way that this is done is highly dependent on the skills of the people involved.

Acceptance of changes is a natural process.

The basic core concept here is that the acceptance of a change is defined by the network.
Much like the network decides which chain to mine. No rules, just incentives for individuals.
People have the incentive to participate in defining the direction of the network only if they feel equal to the others.

Changes are rejected until they are not

The basic premise is that any change-proposal is by default rejected until the push by the owner (with help of the network-discussion people) convinces enough of the network to say we accept it. This is generally done because there is more value accepting it than by rejecting it.

As an aside, this means there is no need for conflict resolution. This way you will make all the professional politicians put in the same amount of work as any other and their acceptance is based on merit, not power.


A Cash Improvement Proposal (CHIP) is a document that is beneficial to anyone that wants to make a change to the network. The main benefit is as a living document detailing the current state of the proposal, preferably with actual technical details.

The exact details of what goes into a CHIP is not detailed here other than to say that the document supports the process. It should help answer often asked questions and generally help people build consensus around (or against) a specific idea.


I agree that introducing a strict process, we would be overpowered by profession lawyers and politicians.

I’ll re-post these wrtitings of mine from last year. I think they can be useful to this discussion.


Do people think it makes sense for me to write this in a blog post for wider feedback?

Seems like we need a CHIP for nailing down the CHIP. :slight_smile:

Right now I have this Multiple OP_RETURN CHIP in progress as Draft. How can I credibly claim it’s beyond Draft status? What “burden of proof” do I need to overcome?

This is from the CHIP’s section on Stakeholder opinions right now:

List of Major Stakeholders


Full node developers

from Jonathan Silverblood:

I believe multiple OP_RETURNs should be adopted, it is highly valuable as it makes it possible for OP_RETURN based protocols to work together to create value. I also believe that counting the aggregate number of bytes is in line with the intent of the original functionality.

Major businesses

Miners and pools

Application Developers

Service Operators

I think that section should be filled up. In particular, application developers are probably the most likely to be affected by it, and other than Jonathan (who also falls in that category) I’ve not seen any statements.

Also, you’ve just encouraged someone to add a short technical spec to your CHIP, so DRAFT at this point seems to be the correct status, no?

1 Like

Thanks - my question was a bit more general about process rather than the specifics of this CHIP. Tom has correctly pointed out that this is a community without specific formal processes yet the CHIP reference provides for states that imply such a thing and that there is some state determinations from Draft to Proposal to Accepted (or something akin to that - I’ve seen more than one state machine suggested) that a CHIP must transition through.

Do we think such state names are concrete goals and therefore have objective definitions for being attained or should they be treated as “suggestions” by the owner in which, once asserted, would be for others to declare their objections?

Tom’s point of “Rejected until accepted” makes sense - but then there should be a directory of various stakeholders that CHIP owners could reach out to directly for those of us “not in the know”. For example, I know no one on the miner side of things whatsoever - not even who they might be.

Finally, as a CHIP, I think the “Multiple OP_RETURN” one is still technically in “Draft” stage for purposes of completing the document but it’s clearly well into a “Proposal” stage in terms of work done and discussions had and awareness built over the last year+ even prior to my participation. This is as much an artifact of the fact that the CHIP “process” is still being defined itself as any suggestion that the “Multiple OP_RETURN” concept is in early stages.

1 Like

My take on status (draft/final/etc) is the following:

the owner of the CHIP is responsible for the quality being high enough to get accepted by enough people to get this activated, which is the main goal. The status field is one more tool they can use towards that goal.

A proposal that is open for review and feedback, and the owner is willing to change the proposal is in the draft status.

At one point it should move to the final state, mostly based on the decision of the owner, but naturally if people are under the impression bugs still need fixing that would go against the number one goal.
As such the main reason for going to final is that implementations can feel confident that they can use the spec included in order to write their code. They can be confident that its not an in-development draft anymore.
Obviously, nothing final exists in this universe and final doesn’t mean immutable.

So, my advice is check what @BigBlockIfTrue wanted to change in your CHIP (multiple op-returns) and if there isn’t any technical changes expected, change it to “final”.

Or, maybe, final is a stupid state for a decentralized system. Maybe its simpler to go action based instead: “ready-for-implementation”.

be creative, do what helps people understand the goals. We are charting new routes here :wink:

1 Like

I do see it more like that in fact…

I think the “Multiple OP_RETURN” one is still technically in “Draft” stage for purposes of completing the document but it’s clearly well into a “Proposal” stage in terms of work done and discussions had

Would agree with that, I think as soon as you think the document is ready to go, it could be moved into ‘Proposed’ or something (if one follows the Leandro / BIP-like state machine)