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
next prev 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