Submission procedure for HF items

#1

To avoid misunderstandings and to ensure that all ecosystem players have sufficient time to make a final/formal review, acceptance and implementation of a hard fork feature, we should define a relatively formal submission procedure. Prior to this procedure, it would make sense for the entity proposing a HF change to work with other people in the community who are “for” this change. I do not think that that process needs any formal definition. However, there needs to be some process that lets everyone else – people who are not interest in the feature, or see it as a lower priority than other items – know that the feature is “ready” for a final review/implementation, and gives those people the tools needed to conduct such work efficiently.

I’d like to propose the following components be supplied to enter this review phase:

  1. Specification of sufficient quality to allow implementation based solely on this spec (not code) and other “standard” specification (e.g. reference.cash).
  2. An implementation branched off of any full node that is currently tracking the BCH tip.
  3. A live testnet. This testnet does not need to exclusively implement the only this feature.
  4. A means to generate/exercise the feature on 3 (wallet, python, javascript code, etc).

Any HF feature can be proposed with a “good failth” effort to implement the above items up to N months before the HF, and must be evaluated by us, with a decision made M months before the HF. Any feature proposed after N months before the HF is automatically deferred to the next HF.

If we end up with a formal body with members, I’d further add a rule that a deferred feature can be “rushed” into the current HF if every member but 2 wants to rush it. But this rule would require some kind of governing body that we don’t have right now.

#2

Heya,
there is a lot of overlap between what you wrote here and the current metodology we have (here).

Your closing paragraph stands out as it is distinctly different from what many of us have been working on in that linked article:

Compare this with what the nice document from mtrycz says;

No formal process can be established for consensus changes, otherwise we’ll be taken over by lawyers and career politicians in a matter of weeks.
We cannot appeal to a central authority either, as we refuse to nominate one. The ecosystem is decentralized and should stay that way.

This difference will be quite useful to touch upon as this shapes the entire way of interacting.

And to repeat, the linked article as written by mtrycz has been going around for many weeks and he has been pestering a lot of people to review on public channels (and in PMs, if we didn’t respond :slight_smile:)

Cheers!

2 Likes
CHIP 2023-07 Network Upgrades only on Saturdays
#3

That final paragraph is a big IF, because it requires a membership body. But its just a minor addendum to allow “rushing” a feature. The rest stands without it.

You can have a decentralized, non-membership based, formal process that won’t attract lawyers and career politicians. Block admission itself is an example.

In fact, as we’ve learned in the last 3 years, an informal process is extremely attractive to career politicians because acceptance can become more about relationships, lobbying, pull, and quid-pro-quo than about engineering and research. If there is no formal admission criteria the job is essentially running around convincing each individual by any means available.

I think that the process I outlined in the first few paragraphs is an example of a decentralized formal process. A submitter can prove via the blockchain commitment, or something less perfect such as a github checkin, that their submission existed by a certain date. Each individual evaluator can independently verify that.

Of course, there will still be opinions that a submission is incomplete, or that a submission is not desirable. But at least we’ve specified a baseline.

#4

I’m lost here, proving you had a proposal at some time in the past is not something that makes me think helps you build consensus in the wider ecosystem. How could it?

Edit: (trying to understand your thinking)

This looks like you are ignoring the actual “on the table” process. The word is “process”, as repeated various times in the article (I’ll link it again for convenience here). What I quote from you is a final product, not a process.

The process is essential because the goal is not to get something ready, that is secondary. The goal is to get the best solution that all stakeholders agree is the best for Bitcoin Cash.

There is not a “submission” which is finished and has some requirements. Such a submission is very likely to be ignored or nicely rejected. I think you took a left turn and missed the point :slight_smile:

Edit2: as you were absent during the building of the DAA, you missed the beautiful biulding of consensus and how the process actually works in real life. I suggest reading my earlier article which goes over this: The story of how BCHs 2020 DAA came to be.

1 Like