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:

7 Likes

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?

Cheers!

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!

2 Likes

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

Similar:

  • (+) 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:

4 Likes

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.

2 Likes

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.

3 Likes

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: CHIP-2021-02_Group_Tokenization_for_Bitcoin_Cash.md ¡ 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.

2 Likes

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.

3 Likes

It seems like you agree with the general idea but not with the details? or I am not understanding the difference.

How does an adequate template not provide an easy to write/read, structured process for collecting information about a proposal into a single document that would provide, when filled out fully, maximum information about said proposal?

This makes sense from a historical record keeping standpoint but not when writing a new CHIP. The outline doesn’t only list categories, it keeps a brief description of what information each section should include. What it doesn’t keep is information irrelevant to writing the new CHIP. The only time the reasoning behind why the template was designed the way it was is during its initial creation and any later discussions about altering it. I think that the other information should be separated into a differen background / historical information that people can read if they need more information than what is on the template they are filling out. I am not suggesting it be discarded. This is why in the MR i wrote:

"I also removed text that explained philosophy about why a section is important because i do not feel it has a place in the document itself. It should instead be included and used as supporting details in the surrounding discussions. "

This explanation seems contradictory to the entire proposal. In the same proposal in which the process for making changes to BCH is being outlined, you are suggesting the process be bypassed for your desired change. By default no change should happen. We stick with the same process and do no-op HF’s when they come up until new release schedule proposals are formally put on the table and evaluated. I do support your proposed release schedule. However, I would like to see it in its own standalone proposal for the upcoming May “HF”. This is an operational issue, not a technical one. People should not need more than a couple of days to form and voice their opinions on a release schedule.

WRT the dispute resolution, you are right. The process you outlined would lead to a very unambiguous outcome and i do not have a counter suggestion at this time. Although I do not particularly like it, rejecting a proposal based on a gut reaction without having a counter proposal is less than unproductive. I withdraw my opposition to that solution.

1 Like

I prefer this:

1 Like

I have seen a lot of discussion about what the CHIP process should be and how it should look. I also offered my own take on what I called “governance” about 5 months ago. I like im_uname’s proposal. I also like Tom’s proposal.

Of course, the two proposals are fairly different in their foci and level of detail. I don’t necessarily view them as incompatible, as im_uname mentioned. Neither is coercive or attempts to be anything more than a guideline. I do like im_uname’s suggestions for process and formatting of CHIPs since this sort of guidance can help people focus their thoughts and make more productive use of everyone’s time as they generally know what to expect in a CHIP.

I’m also impressed by the amount of CHIPs or near-CHIPs already out there (thanks emergent_reasons).

With proposals already out there, I think it might help to shift focus toward the tactical aspects of shepherding them through whatever process they do end up going through. I expect the CHIP governance process to evolve over time and I expect that a lot of the most important changes and improvements will come from practical experience. We just need to get past the 0 to 1 hurdle first. Have any existing CHIP authors committed to follow any particular process? Are they currently “blocked” in that process due to lack of formal venue or anything else?

3 Likes

I wonder if it would be possible to add some categorization to CHIPs as a standard, similar to what is proposed in BIP 0001, BIP 0002, and BIP 0123 in terms of type, layer, and status.

According to the structure of, or similar:

Type

  • Standards Track CHIPs
  • Informational CHIPs
  • Process CHIPs

Layer

  • Consensus
    • Softfork
    • Hardfork
  • Peer Services
  • API/RPC
  • Applications

Status

image

Both BIP 0001 and BIP 0002 mention the figure of a BIP Editor (or a body of Editors?), but the reality is that the role ended up in the person of Luke Dashjr.
I imagine the BCH community would prefer a different approach where more than one person is involved in the “editing” process described in those BIPs. Perhaps some sort of mechanism that allows cyclical renovation of Editors’ group as a subset of well known and proven BCH stakeholders.
Or maybe we just don’t even need that Editors’ group at all.

2 Likes

A status is definitely somehing that makes sense.

The CHIP is a companion document that supports the proposal, it allows everyone to talk about the same details and latest version. As such it is a reflection of what the people supporting it agree about.

It should be easy to make the state be part of that agreement, should the people agree it is “final”, then it is final. And anyone coming in at the 11th hour wanting lots of changes can be told he is too late.

This point, where the CHIP is a supporting document, leads me to believe that we don’t really need an “editing” team.
I expect that editing and writing of CHIPs is something that either the owner will want to do, or otherwise volunteers like myself that have edited CHIPs and host them on our own git. Decentralized, as it were.

ps. I don’t have a storng opinion about the layer and/or type fields. Ideally the title of a CHIP is self-explanatory.

1 Like

A status field was present in the original proposal. It remained in the template i created earlier.

I added two types to the template i created earlier. Technical and Operational. A Technical CHIP would be a CHIP that changes the BCH protocol where as an Operational CHIP would be a change to some non protocol BCH process that everyone is currently abiding by.

Anything that is not consensus layer (or quasi consensus) does not require a CHIP to be implemented into an implementation. You would only desire a CHIP for a non consensus change when attempting to establish it as some standard that everyone implement. DSProofs is an example of this, not consensus but it is desired that everyone support it so a CHIP was made.

I have also added a field specific to providing a link or location where discussion about the CHIP can be found because the discussion is not supposed to be written into the CHIP itself.

A CHIP is not supposed to be the entire process. It is supposed to be filled out when proposing a change for BCH to provide readers with maximum information about the proposal in a single standardised document. The process for approving a change needs to take place in an entirely different discussion. A CHIP is just about what information is desired to be presented for a proposal.

If you would like to compare it to the BIP process, BIPs are written and then proposed to the bitcoin mailing list so the devs can deliberate and decide if it is accepted. The actual approval process under the BIP Workflow section of the BIP documents is very vauge. It does not define any criteria for acceptance or rejection other than there will be a discussion. We want/need a clear definition about criteria for BCH or to at least discuss it.

An interesting perspective of your article btw. I didn’t have it on the radar. Thanks for sharing.

I think you hit it precisely on the spot by saying (emphasis mine):

“In the (very) early days of Bitcoin, all users were also miners and Satoshi had ultimate decision-making power over the protocol due to his status as its creator and the respect that entailed from others.”

This is something super important that many seem to forget when invoking the consensus mechanism proposed in the whitepaper.

I also liked the stakeholder classification based on the work of R. Edward Freeman.

I may not fully agree with the characterization of Users, as you put it, among other things that were already discussed in the article’s comments.

You make a good description of what developers need: support/compensation, and what miners need: revenue maximization. But you don’t mention absolutely anything about what Users need, and that, I think, ultimately has a lot to do with the Store of Value.

Can we understand Store of Value as “compensation” in a broad sense for the value users bring to the ecosystem?

As I see it, any change with the power to undermine Store of Value won’t be welcomed by users.

1 Like

About “a CHIP is not supposed to be the process”:

I am in fact focusing this proposal around a process, because I think it is the most important part. The formatting is secondary to the process. Recommending a decisionmaking process that has clear milestones, outcomes and expected information along the way can prevent chaos, and the formatting I attached is just things I expect out of a persuasive proposal in that process. People can and likely will add their own spice to the format.

But my point is, formatting guidelines by themselves don’t do very much. A “clean” formatting template might be convenient (see also !1, which I need to get to), but they are not the meat of the document either way.

If someone wants to make amends to the formatting, I’m quite open to them! But if the request is instead “let’s not recommend a process here at all”, then that removes the primary reason, in my opinion, of this whole effort. I’m aware that different people have different understanding about what this specific thing named “CHIP” should or should not be, and I appreciate that; but I’m going to focus on what seems (to me) to be the most important thing out of this endeavor. If the criticism is that it really should be called something else, I’m open to suggestions. Cash Improvement Processes (CHIPRs)?


About “operational CHIPs” , or CHIPs on things that are not consensus (or pseudo-consensus, like mempool-policy and network protocol):

Don’t get me wrong, I’m not against them existing, or being discussed, or using this specific format for discussion! I think I need to get that out of the way, so that it’s not misunderstood down the line.

With that said, I tried to focus my effort around consensus/pseudo-consensus proposals because:

  1. They are the most consequential, where failure to reach wide agreement can/will actually lead to network splits.

  2. Conveniently they are also the most amenable to clear milestones and outcomes in most cases without costly elections. Clear information at each step and unambiguous outcomes are necessary, in my opinion, for a process to be meaningful.

Consider a “marketing CHIP” that proposes “Change the official BCH color to purple”. One can probably list lots of information in a similar format, but end of the day, it’ll be exceptionally difficult to have a clear outcome. If it cannot have a clear outcome, then it doesn’t need the relatively elaborate process I’m proposing here.

Q: But wait, I just want to use this format to write a proposal since I like it! I don’t care about the process!

A: You can already do that! :slight_smile:

Q: Alright, yes I can. But if you don’t designate them as an “explicitly recognized class” of CHIPs, wouldn’t the repositories just ignore them, hence my proposal won’t get the exposure it needs?

A: I don’t have any objection about the inevitable repositories that crop up listing any category they want - imo it should be up to each repository. In fact, since having more things listed tend to bring more traffic than less things, I expect many of them to do so!

I think end of the day, the difference is really in emphasis: My primary goal is an orderly process of change that minimizes possibility of split, chaos, dictatorship, and ossification, so the outcome is that my document is oriented around consensus changes and the process, instead of “resolving differences in general” and formatting guidelines. The good news, of course, is that people with different understandings can easily improve in their own ways without even conflicting… unless it’s about naming, I guess. :sweat_smile:

2 Likes

More specifically, you are formalizing a process. As you specify:

and

Now, I specifically quoted this last part because it very clearly has one rather large assumption. You assume that the outcome of an orderly process formalized and specified to rather minute detail. You assume that this will have the outcome of minimizing splits, of avoiding choas and dictatorship etc etc etc.

This is an assumption that you never build out.

A process → no dictatorship.

I don’t follow this assumption. The banking systemt itself is a counter example that started Satoshi .

Chancellor on brink of second bailout for banks

What do you think was the reason for this bailout? The answer obviously is a rigourous list of rules.

This is a rather large counter example. In more recent memory we see a lot more such examples in politics. In short, I don’t agree with your assumption. I don’t agree that the more detailed and thought-through a process is, the less evil can be done. This is true for some people (mostly academics), and I guess you are one of those people and that leads you to think this is true for all. But it is not true for the majority of people.

2 Likes