CHIP Guidelines

[Griffith]

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

The current draft of the guidelines for writing a CHIP along with a template can be found here:

ggriffith/cash-improvement-proposals/-/blob/master/CHIP-2020-11-CHIP-Guidelines.md

I am still looking for feedback/input on what information should be included in a CHIP.

[Jonathan_Silverblood]

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.

[tom]

Would this be the first CHIP?

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.

[freetrader]

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.

[mtrycz]

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.

[BigBlockIfTrue]

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

[mtrycz]

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

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

[Griffith]

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.

@tom

The general idea appeals to the librarian in me: give things a label and make it easy to file and easy to refer to

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.

@BigBlockIfTrue

IMO there is also no need for a central repository,

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.

[tom]

@Griffith

I am now wondering if this should be a list of changes that have been approved rather than proposals themselves. a CasH Implemented Proposal.

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

[Wecx]

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

[Wecx]

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.

[Wecx]

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

[Griffith]

@tom

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.

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.

@tom

If its good enough for wikipedia, I think its good enough for us

that was a good read. thanks. i agree

[freetrader]

I think now that we have the first CHIPs appearing, some things have become more clear to me:

• The versioning in the title is not universally popular (though we might still want to keep it)
• CHIPs are treated as living documents, we expect them to go through a lifecycle (which is why the Status field is helpful)
• Because they evolve, CHIPs should be versioned in some way that allows someone to accurately retrieve a specific version in order to reference. If properly maintained, a “Date” field could serve that purpose, but then we’d need to decouple it from the “should match the year and month in the CHIP name” because it’s very likely going to evolve after the CHIP’s first appearance date).

I would strongly suggest adding a separate “Version” field to the “Required Fields in Proposal”, to explicitly track some kind of easy-to-communicate version. Technically, if the CHIP is kept in some kind of version control system (where and what is up to the author), all of these would provide versioning and there’d be no need for an additional field.

But what we have now is unversioned documents appearing and evolving (as Google docs, as posts in this forum, etc), which is kind of inadequate for this process.

Let’s improve that.

I noticed @tom has already stuck at least one CHIP into version control which is a good start.

I’m not sure whether this forum has some kind of Wiki functionality, but others have pointed out that wikis could be a suitable tool in those cases where people feel put off by Git repositories (I actually think git platforms have improved nicely in terms of web interfaces to discuss and suggest edits to Markdown documents). In the end, I don’t care much about how, since there will be various options that get used, it can even be a dumb manual version field if the author wishes to release his CHIPs as web pages (current and older versions) or Word documents.

[Griffith]

With regards to “Where should chips be hosted so people can go to one place and read them”, I see no reason why the specification websites (which are more or less clones of each other) couldnt also host CHIP information including a link to where the chip discussion is taking place. More often than not i would assume the actual discussion for any given chip would take place on the authors github/gitlab for ease of editing and commenting on the document.

[BigBlockIfTrue]

I see no reason why the specification websites (which are more or less clones of each other) couldnt also host CHIP information including a link to where the chip discussion is taking place.

Moreover, every CHIP should probably include a link to the main discussion location of itself.

[Griffith]

@BigBlockIfTrue

Moreover, every CHIP should probably include a link to the main discussion location of itself.

I added this as a section to the template i made based off of IMU’s proposal here: Trim the existing proposal into an easy to digest template (!1) · Merge Requests · imaginaryusername / Cash Improvement Proposals · GitLab

[Leandrodimarco]

@freetrader

I’m not sure whether this forum has some kind of Wiki functionality,

Discourse allows wiki posts. Here you can find a good description of how it works and the associated properties.

What is a Wiki Post?

At the time of this forum creation, we ran some tests and it seemed to work as expected, but we preferred to leave it for when the forum grew in users and participation.
So at the moment, wiki post functionality is not 100% activated for all trust levels, but it can be with a couple of clicks.

Perhaps the time to activate it has come.

By combining wiki posts (with their revision history) and Discourse tagging system we could offer something practical while robust for CHIPs and related discussions.

Looking forward your comments.

[Griffith]

ggriffith/cash-improvement-proposals/-/blob/master/CHIP-2020-11-CHIP-Guidelines.md

This is a link to gitlab where i have put the chip guidelines and template which should at time of writing be inclusive of feedback from everyone so far. it includes a number of additional required fields put forth by IMU, specifically outlines the CHIP types, and adds a version field to the header as suggested by FT. I have also added field where the author can link to the place where relevant discussion about the CHIP is taking place.

[proteusguy]

So I’m going to assume “best practices” would be to maintain CHIPs in a relevant git repo and link to discussion threads here on bcr. That seem like the way to go? Right now I’m trying to make the time to put the multiple OP_RETURN proposal that I have here into a well formatted CHIP. Unless there’s an objection then this is how I’ll proceed.