public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Luke Dashjr <luke@dashjr.org>
To: Dave Scotese <dscotese@litmocracy.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses
Date: Wed, 3 Feb 2016 00:03:31 +0000	[thread overview]
Message-ID: <201602030003.33208.luke@dashjr.org> (raw)
In-Reply-To: <CAGLBAhdFo2pXcDfvPCTpm7ufQuG8z4mHsdoidGkhB3q5SWLj=A@mail.gmail.com>

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


  parent reply	other threads:[~2016-02-03  0:04 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-01 22:53 [bitcoin-dev] BIP Process: Status, comments, and copyright licenses 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 [this message]
2016-02-03  0:59           ` Jorge Timón
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=201602030003.33208.luke@dashjr.org \
    --to=luke@dashjr.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=dscotese@litmocracy.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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