Upon what data does the CHIP base its assertion that this is a "last-defense effort"? Its based on hopium, like many other statements.
You have to separate that which is informative from that which is normative in any spec or process. In this case, the CHIP outlines a good process to communicate with other participants in the community (in the milestones section). But there is no specified way to exit that section with success or failure. It only states "is sufficiently evaluated (1), did not raise major controversies (2) or inadequacies (3), and have received sufficient support (4), by this date there should be more than one full node team that implements the change (5)." (I added the numbers)
1,2,3, and 4 are matters of opinion. Its also unclear in 2 or 3 whether one person can claim these to block the process. Who determines their validity. Also 4 could be clearly defined but it is not.
5 is the only unambiguous exit statement.
Now, if that state is exited with success, we have a minimum of 2+ nodes with implementations and N without. Perhaps some of those N invoke clauses 1,2,3 and 4, but the other 2+ nodes do not accept those concerns as valid. Now we are heading right to a hard fork split and the CHIP specifies no resolution. At an absolute minimum it ought to state something like "any full node with a minimum of X deployments or wallet with a minimum of Y deployments can invoke 1,2,3,4 to block the feature, even if implemented in multiple other full nodes and activate the dispute resolution process described below."
Above I went through specifics. To make a meta-analysis, you need to abstract those specifics over many feature flows, and you'll find the reason why I think that the "last-defense effort" might be invoked a lot more often than is assumed by the CHIP doc. Doing this extracts the structure of the workflow. In essence, there are many criteria for non-success, that seem to be able to be ambiguously activated by a minority or even just 1 of the undefined participants in the CHIP. Its not even clear how or whether you have a seat at the table, other than full nodes. What a full node is isn't even defined so I suppose if your code can sync the blockchain from the GB you are in?
Whatever you think about BUIP166, please take my CHIP experience as constructive feedback hard earned proposing Group Tokenizations. Ambiguity in this process meant that we had to eliminate many features to try to satisfy everyone. To the point where I'm not satisfied because I want those features!
This is exacerbated by the context of a careful, stable coin: if you can't prove or convince every person of a feature's future value, its out in their opinion. There's no "well, I see your use case but I don't think it will be popular, but since you are doing the lion's share of the work, go ahead".
To explain this in a specific context, we have non-BU people working with and dealing with SLP's problems on a daily basis who asked me to re-propose Groupt Tokens and last I checked remain in support of Group Tokenization as a way to add miner validation to SLP. And we have a full node developer (TomZ) who does not use SLP, but decided that SLP was fine as is and so rejected the Group Tokens proposal. AFAIK TomZ is aware of the testimonials of the people working with SLP. He thinks that if we provide better SLP infrastructure, the problems will go away. No modification of Group features can change that opinion... and we have emergent_reasons who's also against it and nobody knows his ability to invoke any of these CHIP clauses, and there's no way to determine that. This is quite a social maze to navigate.
So based on the CHIP process, this exits the "milestones" process. So that would put us right into "dispute resolution", AKA hash war.
Post automatically merged:
Ok, perhaps I summarized. Let me rephrase.
The CHIP process explicitly gives a non-binding dispute resolution authority to the hash-power majority, which is BCHN and it then rejects its own authority so the real authority devolves back to the hash power majority node, BCHN.
From the CHIP:
"Gain a sustained supporting signaling from over 75% of the BCH hashpower for at least six weeks, via coinbase transactions."
It also offers 2 other avenues to achieve "dispute resolution", without actually bothering to specify which one would win if they conflict. So, oops. But that doesn't much matter because it rejects its own authority by saying:
"It should be noted that this dispute resolution process still cannot, in the strictest sense, coerce any given node team into implementing any change."
It could instead say something like:
"We (the undersigned) hold the BCH name and other properties in trust and commit to ensuring that the chain that these properties reference will contain any feature that meets any of these dispute resolution criteria, unless that feature is proven to have security flaws, in which case we will deliver an equivalent feature. If the undersigned builds full node software or wallets, they commit to providing the feature within a year of successful "dispute resolution" and the existence of a reference implementation (whichever comes last). If the undersigned provides an exchange, they commit to calling the chain that provides these features "BCH", in the case of a fork where one side does not offer the feature."
---
Regardless, doesn't BU or another development team activating all this make no sense for all participants involved?
The dev team needs to prove that the feature is worth the investment of time and money to shepard it through the CHIP process.
The BCH dev community wants assurance that the feature isn't a waste of their time.
The BCH users don't want a bunch of cruft in the blockchain.
The argument that we ought to prove a feature's usefulness before deployment is a strong one. So rather than panic as we go off and do that, let us go off and do that.
Last edited:
). good on Bukele. he knows how to follow up:
