It is true that are many levels of consensus and that term itself is not incorrect for any of the meanings. Maybe we should try to start distinguishing between different types of "consensus". In BIP99 the only concepts that are needed are "consensus rules" and "adoption consensus" (aka "community consensus", "full node runners consenusus", "monetary users consenusus", "economic super-ultra-majority", not sure if any of them or all of them, that's still a placeholder in bip99 for <everything_thats_needed_for_an_uncontroversial_hardfork_apart_from_the_hardfork_new_rules_being_uncontroversial> [ie safe deployment requirements for an uncontroversial hardfork, just like we have for uncontroversial softforks]). Whatever term and defintion we chose for this concept, it has to be neutral to whether the consensus rule changes are can be deployed as a softfork or only as a hardfork [although we have had many hardfork-to-softfork re-designs in the past and I agree that there will be more, some people including @petertodd suspect that SF=HF, but haven't been able to prove it yet], or otherwise we're implicitly giving miners a power of unilaterally changing some consensus rules that they don't have, for users can't never be denied from the right to validate whatever rules they chose, just like an old radio receiver machine owner cannot be forced to listen any channel in particular. The "consensus rules" are in some sense the id of a theoretical communication channel, and should not be confused with a real-life process for how users should coordinate to "upgrade" to a new channel (which is what BIP99 is about) or how we can objectively know whether a proposed changed has had "adoption consensus" or not, which is what this BIP is about.
But yeah, suggestions totally welcomed for a replacement for "adoption consensus". On Tue, Feb 2, 2016 at 8:41 PM, Luke Dashjr <[email protected]> wrote: > (Note Core currently has "consensus" only 249 times, most of which are simply > identifier names, so it would be trivial to make this change.) I'm afraid this would be horribly expensive in development hours for not good enough reason and I must nack. On Wed, Feb 3, 2016 at 1:03 AM, Luke Dashjr <[email protected]> wrote: > On Tuesday, February 02, 2016 11:28:40 PM Dave Scotese wrote: >> How about "defining" (rules, code, etc.) Such code and rules define what >> bitcoin is. It does require consensus and it ends up being a concord, but >> all that can come after the fact (just as it did after bitcoin was first >> released to the public). > > The difficulty is that this BIP needs to refer to three different context of > consensus: > > 1. Consensus (stated) among developers for changes in the BIP Process. > 2. Economic consensus (potential and stated) to veto a soft-fork by an > intended "firing" of the set of miners if they choose to enforce it. > 3. (Actual) consensus in economic adoption of changed rules, to determine the > success of a hard-fork (after the fact). > 4. The set of rules currently established as (defining) Bitcoin, enforced by > an (actual) consensus of economically-relevant nodes. > > Context 3 can be disambiguated with "adoption consensus", and context 4 with > "consensus rules" and/or "consensus protocol", but I don't see a clear > solution that covers all four contexts, and even sharing the word "consensus" > for them may be confusing. > > In addition, usage of the word "consensus" for context 4 has proven confusing > to users. For example, recently users misinterpreted the "Consensus" label > used in context 4 as implying that the idea itself had in fact achieved > consensus among some group of decision-makers (similar to context 1, but not > necessarily the group being "developers"). > > I don't know a good way to make this completely clear, so suggestions are more > than welcome. > > Luke _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
