CHIPs: A more detailed process recommendation

Link to the proposal

After a flurry of feedback on my previous article, I have made some modifications and improvements to the process.

Highlights of this document:

  1. The necessity of well-defined milestones remain unchanged and central to the process, but they are modified according to feedbacks demanding longer deployment periods, balancing that with leaving still adequate time for debate, research and testing.

  2. An explicit dispute resolution mechanism is added via miner and stake vote, and it is expected to be invoked only rarely. It should be obvious that such a scheme is quite costly to network participants, but the ambiguity of not having one last-resort mechanism spelled out may lead to even worse outcomes as witnessed in the past, so it is there.

  3. A background and assumptions section is added discussion some of the rationales underlying choices in this document.

Note that this recommendation and process is not coercive, and indeed cannot be coercive by design. Its power entirely lies in actors who adopt it, and make CHIPs who follow the process a success. I sincerely hope that providing a clearer structure than what Bitcoin Cash has had so far, we can avoid lessons from the past, well into the future.

Hosting location for CHIPs are intentionally left unspecified - they can be hosted and displayed anywhere, centralized or not, only the process is important.

Discussions here, and also in PRs/issues on the repo :slight_smile:


I do hear the criticism of my approach in many of your points, good to have it spelled out :slight_smile: Great work, and the fact that you had patience with me even though my approach was an annoyance gives me faith in this ecosystem!

One question about the CHIP guideline - what dates should we use? The date of when the idea started floating around or of when the CHIP is first created? I put 2017-11 because that’s when the BUIP was originally made.

PS I took initiative and made a CHIP for group tokens, and Andrew joined me in this effort, so that’s decentralized and permissions development, yesss!

Thank you for writing something new.

I would invite you to participate in the various topics that we have been having on this forum as there is quite some overlap. Where there is a difference I would like to suggest to follow the process of getting support for your ideas by suggesting the in a free form before you write them in a more “formal” form of a CHIP.

You now drop quite a substantial document that has not been discussed here before and it now becomes quite hard to build a basis of support in this form.

Maybe it is an idea to start with some of your assumptions and check what people think about them?


Consider me a supporter of this proposal, @im_uname .

I think it summarizes well many of the points discussed for quite some time, gives firm structure to the CHIPs, and the added Dispute Resolution element could be beneficial.

Thanks for this important contribution to establishing a good process!


Regarding stakeholders, what do you think of giving a little structure to it? Here’s a taxonomy I thought of, we could further improve it.

Stakeholder Cost and Benefits Analysis

General costs and benefits, applies to all in the levels below, etc.

Every node of this tree could use a format like below to assess impact:

  • (+) For benefits/rewards
  • (-) Costs/risk
  • (0) neutral

We could then ask stakeholders to comment on whether they agree or not, and why. A single stakeholder could find themselves in multiple categories.

1 Node Stakeholders

1.1 Miners

1.2 Big nodes

Businesses that require a node like exchanges, block explorers, backbone nodes, etc.

1.3 User nodes

Hobbyiest full nodes.

1.4 Node developers

2 Userspace stakeholders

2.1 Business users

2.2 Userspace developers

2.3 Individual users

3 Holders and speculators

3.1 Long

3.2 Short

Yes, I want to include these too, here’s why:

  • (+) More liquidity in the market. We are hoping developments like this will keep you informed and move you towards switching side!

4 Opinion holders who are not stakeholders


  • (+) We are hoping developments like this will keep you informed and move you towards becoming stakeholders!

As mentioned in the document, the success or failure of it, and similar procedural documents, lie entirely in the successes (or rejections!) of CHIPs that follow it. Strictly speaking, it is not even incompatible with other competing processes that manage to gain adoption, unlike actual consensus CHIPs!

Therefore, I expect minor modifications to be submitted as pull requests and major alterations to be hosted elsewhere; either way, it is best for this document to be published as early as possible, as widely as possible. By nature it can evolve permissionlessly, and does not benefit from extended private circulation.

Also note that even if most people end up following a very modified version of it elsewhere, I’d still consider it a success, it has served its purpose. :slight_smile:


Go for it in your proposals. If your proposals are successful then others will imitate.
Personally, I think it’s more effective to let structure like that emerge from experience.


The proposal by @im_uname is an open communication.

I disagree that proposals have to be incomplete to be presented.

What is presented is what is there for discussion, the scope of it is up to the author of a CHIP.

In this case, it’s mostly an aggregation of thoughts and suggestions that @im_uname has already presented in various fora and formats over the last months, so as a reader I’m familiar with the arguments, and practically only the Dispute Resolution idea was novel to me.

Additionally, I think he tried hard not to set anything about this process description up as a “winner/loser” factory.

Ultimately, I think it’s a great process template to work off, at least as a starting point for CHIPs, and adds clarity to those wanting to participate.

1 Like

It’s not actually that long, took me maybe 20 minutes to read over, and a little more to think about it.

Compared to a technical proposal - they can also be short but complex, or even short, simple and yet expansive in their consequences on the system.

As far as a process description goes, I’d say it’s fairly succinct, most of the document is concerned with explaining the ‘why’ and a significant part relates to the other options.

Going to other people’s repos and submitting merge requests is just a normal part of an open source / decentralized process.

I had to do the exact same on your CHIP repo and I didn’t have a problem with it. Besides, if an author is stubborn, the licenses should always allow forking and updating elsewhere, and @im_uname encouraged this explicitly in case of disagreements.


At the time of writing, I am under the impression that the proposal linked in the OP is meant to serve as the CHIP about how CHIPs work similar to how BIP1 and BIP2 explain / outline the BIP process. Thank you for taking the initiative on writing this. I had not taken the time to sit down and write out a full document like this when I initially proposed CHIPs. I have been gone a bit recently but now that I am back I am glad to see CHIPs have attracted more interest.

A CHIP was intended to be an organisational step towards being able to keep track of proposals as well as provide a general outline/template of everything a proposal needs. In my original proposal and the following discussion thread I mentioned a few times that a CHIPs are meant to be a “improvement proposals for BCH”, I would like to make it clear that I used general phrasing intentionally because I feel that they should be used for operational proposals as well as technical proposals. It is also worth noting, FreeTrader has previously mentioned in the discussion threads that “CHIPs are treated as living documents, we expect them to go through a lifecycle” and I completely agree with that statement.

I feel that this “Detailed Process Recommendation” document detracts away from the original intention of what a CHIP is by including some extra stuff that should not be in there. There is nothing wrong with the proposed contents, I simply do not feel that packaging everything into one document was the right choice. I feel that some of the details you outlined in this document should have been done in a CHIP themselves. I am strongly of the opinion that this document should be broken into two smaller ones.

  1. A template for creating a CHIP. You have done a good job at expanding my initial short list of categories into sections that give details about what should go in each section. Uniformity in format amongst all CHIPs will certainly make things easier to work with. For this template document, I think the “Summary” section at the top and all sections “Motivation and Benefits” and below should be included.
    This CHIP is a good example of following the outline: · master · Anonymous Contributor / Group Tokenization · GitLab
    The CHIP about CHIPS should provide this template with minimal extra information that is not important to the CHIP writing process itself. The template is defined in the proposal linked in the OP but it contains extra stuff that should be moved out of it.
    We should add an additional field to the outline that defines the different types of CHIPs. At a minimum I think there should be 2 types of CHIPs, operational and technical. A technical CHIP is the type of proposal we are accustomed to. Propose the change in consensus rules, provide details, etc. An operational CHIP would be a change to the general process used by BCH. The next section below is an example.

  2. I think everything under your “Scheduled Upgrade” section should be an Operational CHIP itself. Maybe i missed something as I have been gone a bit lately, but I am not aware of any real move towards a consensus on if / how we should change the 6 month release cycle. I have heard proposals that range from don’t change anything to HF once every couple of years. Making a CHIP for this would be a good way to have a discussion about it and come to some sort of consensus on how it should work. Then finalise CHIP and make it the rule (until a future CHIP replaces it if one ever does). WRT the actual release schedule outline you have proposed, I am generally in favour of and agree with your reasoning although I only read it today so I have not had much time to think on it.

I do not know what i think about your “Background, assumptions and principles” section. Its nice to read, thank you for explaining your thought process but i am not sure of it has a place in either of the documents i mentioned above.

I have an issue with is the “Dispute resolution” subsection. I think we have enough evidence from past conflicts in the greater bitcoin community to come to the conclusion that unless miners are overwhelmingly pressured into doing something, they generally do not like to signal or vote on anything. Getting them to do anything requires a lot of time and effort put into lobbying. I do not think this should be incorporated into any dispute resolution process. I am also weary of lobbying custodial exchanges to support a certain viewpoint especially after the recent move by OKCoin. I am of the opinion that even the exchanges that voice support for BCH do not have the same care for the coin as we do here. They can and will survive without BCH, we are just another coin in their books.

1 Like

Thanks for the reply. I’m mostly viewing this issue from a practical standpoint -

“How do we get a realistic to execute, structured process so participants have maximum information, so that outcomes become clear almost all the time, to stave off muddy, prolonged, chaotic and destructive conflicts of the past?”

The document I posted is intended to outline how to do that, it is not just a “template”, hence the loads of background, observations and assumptions.

If someone else have a better way to do that, I welcome them, but I do expect any such efforts to be as structured as mine or even more so. There is not much room for us to leave things ambiguous and open-ended; conflicts with rise without a concrete process, and BCH will fall into one of the much worse alternatives:

  1. The protocol ossifies as conflicts get longer and muddier (see also: BTC).

  2. Without a clear process to do things and clear milestones to force outcomes for a given cycle, a dictator rises, even a reluctant dictator, by necessity. We have already seen that happen once. The more structure and information you put into a process, ironically the less power any one person or team has, as they too will be bounded by clearly observable rules and information.

  3. The chain falls into utter chaos and splits.

I think we can all agree that none of the above are desirable, hence the need for a more structured process.

Some other things:

The dispute resolution part is meant to be costly, difficult and only invoked rarely; if someone invokes the process, miners are already “overwhelmingly pressured” into doing something. If they don’t particularly feel the need to step up and participate, perhaps the issue is not important enough, and the CHIP proponent (or detractor) should simply back down.

Having support from at least one custodial exchange is also necessary for the success of a dispute; without which the process will simply fail, it does not matter how we want it to be. The miner and stake signals have similar purposes; without them the challenge has no chance of success anyway.

Once a dispute is formally raised the chain is effectively in what would lead to a crisis in the past, except this time the crisis can be resolved in a high-information and structured way, with a clear outcome, so that there’s less chance of a split in the end. Hence ongoing cost isn’t as much an issue, because the alternative is much worse.

If you have a better way to do dispute resolution, please recommend one! But I do expect any such process to have an outcome as unambiguous as mine, if not more, with participants having similar real powers as the miner/stake/exchange trio.

It is nice to think the schedule should/can be a CHIP that itself seeks a wide consensus, but experience in the past few months led me to the conclusion that it’s likely impossible given the extremely wide spectrum of opinions, and incredibly rigid positions of the opinions. At some point someone has to just put things on the table that at least has a chance to gain begrudging acceptance from most people, and then it will simply be “accepted” or rejected de facto, depending on CHIPs that follow it.

That’s by no means a pretty way to do it, but consider the alternative. The alternative is the abyss (see also the three likely outcomes above), and the abyss will come really soon. I think I very much prefer having a practical process on the table and getting flakked for it, than leaving things open-ended and seeing things rapidly devolve into chaos or dictatorship as November approaches.