CHIPs: A more detailed process recommendation

[im_uname]

@tom

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.

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.

[emergent_reasons]

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.

[freetrader]

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.

[freetrader]

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.

[Griffith]

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.

[im_uname]

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.

[Griffith]

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

@im_uname

“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?”

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?

@im_uname

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.

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. "

@im_uname

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.

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.

[tom]

I prefer this:

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. Goals The first goal is to learn from past mistakes, BCH has failed to be properly managed t…

[gotamd]

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?

[Leandrodimarco]

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

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.

[tom]

@Leandrodimarco

Status

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.

[Griffith]

@Leandrodimarco

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.

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.

@gotamd

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.

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.

[Leandrodimarco]

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.

[im_uname]

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!

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.

[tom]

@im_uname

I am in fact focusing this proposal around a process, because I think it is the most important part.

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

@im_uname

Recommending a decisionmaking process that has clear milestones, outcomes and expected information along the way can prevent chaos

and

@im_uname

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

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.

[bitcoincashautist]

I keep asking this question and only getting opinions about what the process should be.

I’m quoting George Donnelly from a recent thread on Reddit, and it prompted me to write a few thoughts about the process and share my perspective

Following the process is no guarantee of success, and not following it doesn’t mean it can’t get implemented, and that it is a recommendation, not a rigid thing. We are not a corporate, we are FOSS grass-roots project which really cares about avoiding dictator capture or “process lawyers” appearing, like: “I followed the process, therefore you MUST do X.” or “He didn’t follow the process, therefore we MUST dismiss it just because.”

If an idea is good, it’s good on its own whether it followed a process or not. IMO, the process is there just to help it get into people’s heads, to better focus discussions about the idea, and assure everyone that there’s not something we’re overlooking about the idea, and to get help in shaping it better! I don’t like this be framed like an idea creator presenting it to some committee. Why shouldn’t members of this committee jump on the other side and help move the idea forward? After all, what we introduce into Bitcoin Cash is supposed to benefit us all, so help each other move good ideas forward! That’s what I see is already happening, so yay for that!

You will notice that different people have different ideas about the process, and that’s fine! Different people have differently wired brains and different things appeal to them. imaginary_username requires things to be more rigid. Thomas Zander would like to see things organically appear. Griffith is somewhere in between. emergent_reasons likes to let things… emerge So what to do?

Just pick whatever strategy you think has the biggest chance of success and get started! Be proactive!

That’s what I did and it seems to be moving the ball. Is my way the best way? Probably not, I know I broke some norms annoyed some of you at the start, but then again I am me and someone else is someone else, and he’ll pick another way. There are many ways to get there, and you have to adapt along the way. We should not let this waiting on a process be a blocker. This is permissionless FOSS, you just do it the way you think it should be done, and maybe others will follow. And maybe it’s not enough to follow just 1 process, because different people require different forms when they’re thinking about an idea and you have to give it to them if you want to get in there.

We have to manage people’s attention spans, too. Present the idea in manageable pieces instead of one big document which will be intimidating to read. So I’ve been writing, a lot, casting a wide net of sorts, an then looking at what it caught, and it brought me some good discussions and I discovered what people’s main concerns were so that informed the way I wrote the CHIP. Learning by doing

I couldn’t have invented group tokens on my own, but I could recognize their potential and value, and at that moment I felt responsibility to do something about it for the Bitcoin I care about, and that’s when I stopped being a bystander in this community. All of these CHIP discussions (I count 3 of them) were a great help in showing me the way.

[Leandrodimarco]

Reading the various opinions concerning the subject gives me the impression that many of the differences are driven by semantic connotations. As I see it, these semantic connotations revolve around the concept of process and the guarantees –or non-guarantees– of success that a particular project, action, or initiative can provide.

I won’t succumb to the temptation of copy-pasting the definition of process here. I’m sure if we stop for a minute to think about what a “process” is, we can all quickly come to a shared understanding or common ground.

We can say that having a process in place does not guarantee a solution of continuity, just as not having it does not guarantee the opposite, as well mentioned by @bitcoincashautist.

Even so, processes are proposed, discussed, and implemented in an exorbitant number of initiatives, whether corporate or FOSS –I don’t see these two as mutually exclusive, but just for the sake of the example– worldwide. The literature takes good care of the benefits of having processes with a certain degree of standardization. Although processes are not the philosopher’s stone by themselves, they can pave the way between the launch of an initiative and the goal to be achieved.

Once the aspect of around process and its benefits are solved, I suppose we fall into the realms of old human nature. In the end, we are all little machines working under the precepts of intentions, incentives, and rewards. Perhaps we should ask ourselves again about our intentions regarding this initiative, our incentives, and what rewards we hope to obtain, either for ourselves or for the Bitcoin Cash community.

I’m very much in line with the idea that the process is here to help spread ideas, to guide analysis and discussions. But for me, this needs to happen in a broad sense, not limited to a single or specific aspect of the network’s development. Of course, this is when the component of intentions appears again, and that is just right because different intentions can work in towards greater diversity.

Different aspects of the network may require more or less standardized processes; some, by their very nature, may require a greater or lesser degree of formality, some may allow a greater degree of flexibility. Different actors may want to focus on one aspect or another. But that doesn’t make the aspect in need for higher formality more important than others. It merely makes it particular and different, with value in itself. As well as other aspects will have their value.

It’s essential to me to maintain the sufficient and necessary structures to offer this possibility, to provide the basis for opening new fronts and not closing them. Luckily, to do so in Bitcoin Cash is relatively easy –at least easier than others . Due to our ecosystem’s decentralized nature, actors have the fundamental right of free initiative. Although this free initiative has no means to be prohibited, it can sometimes be relegated or not sufficiently encouraged. And that’s the part that worries me.

On top of that, sometimes it gives me the impression that we are trying to re-invent the wheel. We have a system that works quite well, it’s not perfect, but it served the purposes of Bitcoin for all these years, the system of Bitcoin Improvement Proposals (BIPs).

The system is not original from Bitcoin, but it is based on Python Enhancements Proposal (PEPs). Many of the formatting ideas, as well as the Type and Status classifications, come from Python. Time later, BIP 0123 brought the Layers specification, adding even more value.

In my opinion, these BIPs’ three components: Type, Layers, and Status, work amazingly well. They allow the necessary operability, granularity, and flexibility for the development of Bitcoin Cash and improvement proposals in an inclusive, comprehensive way.

Surprisingly enough, this system considers the presentation of processes, information, and aspects related to Bitcoin Cash development that are not necessarily part of what we understand as Consensus itself. And that, I think, adds an interesting dimension to it. Does that diminish the importance of Consensus aspects? It does not, not at all. In fact, I believe that Consensus as an abstract entity can benefit from the diversity that BIPs’ classification proposes.

If something is working correctly, why change it?
Good question.

Is there room for improvement?
Yes, there surely is, but that doesn’t mean we have to invent a whole new system.

In short, I propose to maintain BIPs format and classification (Type, Layer, and Status, with their corresponding classes) for CHIPs. Let’s identify the ideas and practices around BIPs structure that need to be improved and propose the changes based on that, not changing just for the sake of change.

I like to think that Bitcoin Cash is the closest Bitcoin implementation to Satoshi Nakamoto’s project. The shared history is undeniable. And this brings up some perhaps uncomfortable questions…

Can BIPs be considered as CHIPs??
At least until the moment of Bitcoin Cash inception, I would say yes. Perhaps it’s not the most politically correct answer. But isn’t our protocol in good part governed by what those BIPs express? With that perspective, those BIPs can be considered a subset of CHIPs.

Should we rename pre Bitcoin Cash BIPs as CHIPs on our servers/platforms?
Please do not. I assume the community would like to keep track of history as it is.

Hold on, if you say that every BIP (before Bitcoin Cash) can be considered a CHIP, why bring the CHIP name to happen?
There are undeniable logical reasons for that. At the end of the day, we are Bitcoin Cash. Continuing to use the BIP name for current Bitcoin Cash development would only add confusion, despite the improvements we would like to apply to BIPs concept.

What should we do with the BIPs post Bitcoin Cash inception? Or how should we consider them?
I do not know. Probably we should ask ourselves if there is any value in them that can be applied to Bitcoin Cash. I’m going to let people with the required experience answer that.

And what do we do with all the specific Bitcoin Cash development of these last four years?
To the responsible actors of these developments, I would recommend creating corresponding CHIPs, with the original dates for the proper historical record and the Bitcoin Cash community’s benefit.

Should CHIPs have their own parallel numbering or continue from the last BIP number (until the moment of Bitcoin Cash inception)?
I do not know.

Should we make format and classification (Type, Layer, Status) be mandatory for CHIPs?
Given Bitcoin Cash decentralized and open-source feature, I don’t think there is a way to impose it. And if it exists, I don’t think imposition would be the best option either. But I do think it should be explicitly recommended to improvements’ proponents, at least that’s my opinion.

Let’s write together the CHIP 0001 (if necessary) with all the recommendations the case requires, including formats and associated processes. Or let’s include associated processes in other CHIPs if that makes more sense. In any case, it is clear that people are working on it already. This work will probably require some time and several interactions between different actors but it should not impede the flow of incoming CHIPs reaching Bitcoin Cash. There is always time for formatting and minor adjustments, but that should not prevent the spread and discussion of ideas.

I base my proposal on what I believe will translate into stakeholders’ –users, developers, miners–greater participation in Bitcoin Cash development and continuous improvement. I am convinced these are great times for Bitcoin Cash.

[tom]

Thanks for a very well thought through post. And I agree that we can use CHIPs as essentially the same thing as BIPs were used (and PEPs before that).

The design and topics around CHIPs are not really the process, though. They are a side-product of the process. Actually, they are a tool.
So, while I feel its really useful to talk about CHIPs/BIPs/etc, I feel that it is easy to overthink it. Going further than the items you mention, type, layers, status, etc. is like a project debating class-naming before the coding started. Debating the chapter-names before the book is written.

Do we want some guidelines of what is useful to have in a CHIP? Absolutely.

Does it have to be documented in something that is likely longer than 90% of the future CHIPs? Not so much.

A Chip is a tool used in the main part of the process: reaching a wider understanding and getting a proposal ready for inclusion. Proposals will change between first idea and when reaching the finish line. People will need to understand it in order to accept it.
That is the real process. And the Chip will have to follow the needs and wants of the wider community in order to actually support the goals of this process. And that drives the content.

Which is why I made the much simpler process here makes more sense as a starting point.

A process towards acceptance of Bitcoin Cash Improvement Proposals

[Leandrodimarco]

@Tom, happy to see there are some aspects around CHIPs effort that we can agree on.

I agree with you that the classification I refer to in my previous post is not the process. But it was never my intention to present it as if it were. If I left to imply otherwise with my comments, I must admit that I did a poor job delivering the message.

I mentioned and recommended that classification because my analysis led me to think that it would bring more value to Bitcoin Cash. Simple like that.

But I did mention my concerns about the different perspectives rising up all over the place (exaggeration granted ) about the concept of process. That gives me a bittersweet flavor. On the one hand, it’s fantastic to have space and time (particularly time) to debate what we consider best for Bitcoin Cash. On the other, it’s a bit frustrating that after so many years, we cannot agree on what a process is or should be for Bitcoin Cash, and we end up lost in a slo-mo tornado of byzantine discussions.

Please, have in mind that at this point, I have proposed no single process. I have no intentions otherwise. But if you allow me, talking about this matter with fellows and peers, I get the impression that there is some confusion about the following:

1. What a CHIP is intended to be. Is it a process by itself?
2. The process for CHIP creation/drafting.
3. The process for CHIP status evolution.
4. The process of how/when a CHIP is accepted (or not) by the community and its final activation (or not). At least for CHIPs falling into Consensus Layer, those are the ones rising more attention.

In relation to what I do not agree so much, I don’t feel like we are writing a new book, just for the sake of your example. The book started to be written 12 years ago. We are just a bunch of continuators. Probably our big mistake was not having CHIPs immediately in place after Bitcoin Cash inception. We ended up paying the price of such a mistake. This is important in the sense to realize that we are not starting from zero.

Same for the relative extension of the document that describes a given process for a given subject. Does it drop value just because it is longer than the subject itself? I don’t think so. Does it necessarily need to be longer? I don’t think so either.

I do think that it just depends on what we need for a process to be. In that regard, I’m with you when you say:

@tom

A Chip is a tool used in the main part of the process: reaching a wider understanding and getting a proposal ready for inclusion.

I find your proposal: A process towards acceptance of Bitcoin Cash Improvement Proposals interesting, but I must admit I expected a more detailed process for acceptance of changes by that title. Or I probably missed the point. I come from natural science, so when you say:

@tom

Acceptance of changes is a natural process.

you are setting the bar quite high . At least for me.

On another note, again my personal opinion, the first goal should not be

@tom

The first goal is to learn from past mistakes,

but actually propose an improvement for Bitcoin Cash. Right?

Besides that, I find your proposal very appealing, to be honest. And I admire your passion to keep us away from rigid structures resembling centralized systems. But I will defend the right of free initiative of other Bitcoin Cash’ actors to add/propose a more detailed process and hear their motives. More on this line soon…

[tom]

Heya,

I’m so happy to see my idea in the other thread get lots of likes and open discussion.

@Leandrodimarco

Probably our big mistake was not having CHIPs immediately in place after Bitcoin Cash inception. We ended up paying the price of such a mistake. This is important in the sense to realize that we are not starting from zero.

This is why I wrote that our first goal is to learn from past mistakes
Past mistakes are humans way of teaching us. Past pain is the best teachning method. Lets make sure we actually take advantage of this natural method, even though talking about past mistakes tends to be a painful process.

@Leandrodimarco

I find your proposal: A process towards acceptance of Bitcoin Cash Improvement Proposals interesting, but I must admit I expected a more detailed process for acceptance of changes by that title.

Most people don’t learn by reading someone’s instruction manual. Hell, the majority of us find it difficult to follow a non-trivial recipe from a cooking book! It just isn’t how humans work. So the process of a bunch of humans working together can’t work if you write it too detailed. The 25KB document imaginary wrote is very impressive. It is also not going to be fully read by anyone that starts this process. And thus you get to the point where people just ignore the document.

The bottom line here is to formulate your goals first and let it flow from there. One person (even if IM had help) is simply not capable of representing the wide variety of participants in this future process. So letting it flow from there means we must keep the goals closer than the rules and check ourselves while we figure out how to do this.

And this is why a simpler process is actaully more complex. You get a cooking book saying “Some sugar to taste” instead of exactly how much. This is more difficult to use, mistakes will be made.

But the focus now is on people, not process. The focus is on goals and outcomes, not rules. The focus is on leaving no outliers lie, as opposed to telling them they should follow the rules. And the most important part is that the focus is on participants that want the same things we want. We give no handholds to those that seek to abuse a process in order to do what everyone clearly agrees is wrong. I’ve been there, its a devastating thing to see ( MS OOXML).

Longer documents with rules take away power, take away the ability for individuals to decide. This is a human failing. People that work where there are lots of rules give up decision making power and even stop trying to think critically. Does that vibe with a movement that aims to move the power from the state to the individual?