From: "Jorge Timón" <jtimon@jtimon•cc>
To: Luke Dashjr <luke@dashjr•org>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses
Date: Wed, 3 Feb 2016 01:59:58 +0100 [thread overview]
Message-ID: <CABm2gDr62=_xXPh0f1pE+=DW3X2J_C0fmdN+g7rnqy51S1a1Fg@mail.gmail.com> (raw)
In-Reply-To: <201602030003.33208.luke@dashjr.org>
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
next prev parent reply other threads:[~2016-02-03 1:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-01 22:53 Luke Dashjr
2016-02-02 5:50 ` Dave Scotese
2016-02-02 7:54 ` Luke Dashjr
2016-02-02 16:00 ` Dave Scotese
2016-02-02 15:58 ` Gavin Andresen
2016-02-02 17:38 ` Jorge Timón
2016-02-02 19:41 ` Luke Dashjr
[not found] ` <CAGLBAhdFo2pXcDfvPCTpm7ufQuG8z4mHsdoidGkhB3q5SWLj=A@mail.gmail.com>
2016-02-03 0:03 ` Luke Dashjr
2016-02-03 0:59 ` Jorge Timón [this message]
2016-02-02 19:08 ` Luke Dashjr
2016-03-10 0:37 ` Mustafa Al-Bassam
2016-02-04 4:15 ` Luke Dashjr
2016-02-04 17:45 ` Ryan Grant
2016-02-04 21:17 ` Luke Dashjr
2016-02-05 0:09 ` Ryan Grant
2016-02-02 6:35 Ryan Grant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABm2gDr62=_xXPh0f1pE+=DW3X2J_C0fmdN+g7rnqy51S1a1Fg@mail.gmail.com' \
--to=jtimon@jtimon$(echo .)cc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox