CasH Improvement Proposal (CHIP)

We do not yet have a naming convention for improvement proposals for BCH. Thus far everything has been attached to a hard fork or is a BIP. It is easy to keep track of ideas and proposals right now because there are so few. Eventually this will become harder.

For organisational purposes, I am proposing that we adopt CasH Improvement Proposal (CHIP) as the convention of naming improvement proposals for BCH.

Current Proposal Details

  • Naming convention
    • CHIP-Year-Month-Name
      • The name should be 5 or less english words.
      • Order within the scope of a month alphabetically by name
  • Licensing
    • Required license TBD, but the proposals need to be published with an appropriate license. Creative Commons or MIT should suffice. More discussion on this is needed
  • Required Fields in Proposal
    • Title (should match the name in the CHIP name)
    • Author
    • Date (should match the year and month in the CHIP name)
    • Status (draft, approved, implemented)
    • Motivation (technical and social)
    • Specification
  • Optional fields
    • Link to reference implementation
4 Likes

Sounds good to me.

As long as it doesn’t result in people having incorrect expectations as a result of too clear similarity to another process, it would be great to have easy to reference unique identifiers.

1 Like

Would this be the first CHIP? :slight_smile:

The general idea appeals to the librarian in me: give things a label and make it easy to file and easy to refer to. In that regard I think this is great.

There are a lot of things that need to be pointed out and need attention based on the difference between Bitcoin Core and Bitcoin Cash. Let me try and point out what I see so we all are on the same page:

  • BTC follows the idea that there is a reference implementation and therefore there is a link to a (series of) commits. The huge downside of this is that the quality of most specifications suffer immensely.
    There has to be a requirement that all implementations can implement a compliant version purely from the written specification.
  • BTC is by devs, for devs. And this shows in the BIPs where there is a large part describing why this proposal is “needed”.
    In Bitcoin Cash changes only happen when the community want it, and people that read specs are a tiny minority of this. So the convincing of need for changes need to happen elsewhere. Not in the CHIP.
  • Following the previous point, a CHIP is a supporting, technical document for a wider discussion held elsewhere. And this implies that no author can get any rights from having a CHIP, there is no expectation of changes going to be accepted just because you have a CHIP. (setting expectations).

There is also the question of unique identifiers. A decentralized system allows assiging an ID without any central party giving them out. And this implies that its probably not useful to use numbers, or at least not numbers alone.
Some system has to be suggested that lies somewhere between the easy-but-centralized numbering and hard-but-unique idea of doing a sha1 of your document.

Maybe the simplest solution is to have proposals leading with 4 digits for year, and followed with a name of more than 2 and no more than 5 short english words.
So: CHIP-2020-Cash Improvement Proposal

Edit: suggestion was made elsewhere that we can add months (2020-11) at the start should we want that granularity. May be useful indeed.

3 Likes

I like CHIPs.

Since there’s no central authority to hand out numbers, …
I think @emergent_reasons mentioned something about a “permissionless labeling system” which I think would be useful as a concept.

Not sure where that was described so far, but it’d be useful to have some way of ordering CHIPs, most naturally according to dates raised, but also to have an idea from the name of what the CIP is about.

Just saw @tom’s post above, that sort of naming is in line with that I’d hope for.

3 Likes

I’m sold on CHIPs.

I’m a fan of sculpting them in the blockchain. Since @pokkst has implemented memo in bitcoincashj, if there is sufficient interest, I could spend an afternoon putting toghether an MVP for that.

1 Like

Personally I was hoping for BCHIP (analogous to bcash), but CHIP is ok too.

While convincing the community needs to happen elsewhere, it is convenient for spec reviewers if they understand the reasoning behind it, so I would still like to see a technical motivation in the introduction of each proposal. Both developer discussion and community discussion are necessary (the latter can be brief if uncontroversial).

I don’t think numbers are needed. I like Tom’s naming convention, although I’d remove the spaces.

IMO there is also no need for a central repository, peer review can be done in a repository of the author’s choice, and then the resulting spec can be copied to other places if/as desired, which should contribute to decentralisation of authority w.r.t. upgrades. Of course specs need to be placed under an open source licence - I suggest a flexible licensing policy similar to BIP2. (BCHN plans to transition upgradespecs.bitcoincashnode.org to per-document licensing which would accommodate this.)

2 Likes

The core functions are there, like posting, liking, replying, etc.

I’m fairly certain I DM’d you recently on what exact things you needed wrt Memo support, but I never got a response back.

So if things you need are missing, feel free to contact me.

Hey! sorry, must have missed it amongst the daily chores.

I’ll certainly contact you if I have questions. Thanks!

The purpose of this topic is to implement some sort of standard format and naming convention for improvements in BCH because naming changes unrelated words/phrases like “magnetic anomaly” and “graviton” does not help anyone.

I like the naming convention outlined by Tom with the update of the months that someone suggested later.
CHIP--- is good. if multiple happen to arise in the same month, ordering alphabetically should suffice.

Based on the comments about ensuring that this is not seen as the process for changes in BCH but rather some supporting evidence, I am now wondering if this should be a list of changes that have been approved rather than proposals themselves. a CasH Implemented Proposal.

This statement by Tom sums up my motivations for wanting a naming system perfectly.

On the topic of licensing, that is a good point. it should be a requirement that they be published under an appropriate license. one of the creative commons licenses or the MIT license would be good.

i would like them to, at a minimum, be listed on the spec reference websites such as reference.cash to ensure there is at least one place where they can all be found

I will keep the OP updated with the feedback as people leave it.

One question that this raises is: “Approved by whom?”.

Approval and permissionless-innovation have a rough relationship. They tend to avoid being in the same room.

one of the creative commons licenses or the MIT license would be good.

Something specific for documentation may be useful to consider here; GNU Free Documentation License - Wikipedia. If its good enough for wikipedia, I think its good enough for us :slight_smile:

1 Like

‘Ecosystem Impact Report’ would be nice, what kind of changes would have to be made to wallets, etc.

It’s whatever, it shouldn’t be complicated, just call them whatever you want when you make one and whoever wants to compile them can. That’s what I think.

Very well said, there isn’t any authority anywhere to “approve” anything.

by approval i meant undergoing and completing the entire proposal system that has been / is being put into place. once it has been widely accepted that said change will be implemented into a majority of the bch ecosystem. approval was a bad term to use. “reached a consensus on acceptance” would have been better.

that was a good read. thanks. i agree