MIME-Version: 1.0
In-Reply-To: <201602030003.33208.luke@dashjr.org>
References: <201602012253.18009.luke@dashjr.org>
	<201602021941.25382.luke@dashjr.org>
	<CAGLBAhdFo2pXcDfvPCTpm7ufQuG8z4mHsdoidGkhB3q5SWLj=A@mail.gmail.com>
	<201602030003.33208.luke@dashjr.org>
Date: Wed, 3 Feb 2016 01:59:58 +0100
Message-ID: <CABm2gDr62=_xXPh0f1pE+=DW3X2J_C0fmdN+g7rnqy51S1a1Fg@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP Process: Status, comments,
	and copyright licenses
Precedence: list

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 <luke@dashjr.org> 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 <luke@dashjr.org> 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