1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2C956F2B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Feb 2016 01:00:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f47.google.com (mail-vk0-f47.google.com
[209.85.213.47])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 37F68181
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Feb 2016 00:59:59 +0000 (UTC)
Received: by mail-vk0-f47.google.com with SMTP id e64so4000328vkg.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 02 Feb 2016 16:59:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=G1+u01zwulDitNq6tFH13IDzTOmB1P6rx1lQKUZEKyA=;
b=gYi+7qML9Xs8qtc0Iso3VRKNy4JIVaU6PtEa3urAMy1pQMINJRzpqoUz+16yZ/h3eU
hM8ZqqvLYA9NKmjccPnvPEMxDwkrDx7Iig3nHhGU+EtLoEWz3w3v4An3Lr7IkZhnlOKX
hpPStOx9FKUORMRQItOHzkOBhHhC3ZjTIcD77x9MFbewOodMaOT1R0AYl1IFdn9izusA
myvBc7qIXAge3RD7cnMmQnDNnI4dw5wS9VAUiaDqJ/x1D6jKqC7XKNvDAGJXVSZKnRQn
fgCGwUdvU1mS2EfLqc43ax3bME5gFOPJjAw3vSKV4Eb872HN1GED0l5XYqdd95zMGfLv
mm7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=G1+u01zwulDitNq6tFH13IDzTOmB1P6rx1lQKUZEKyA=;
b=chVsHGwKci0nRzmc/zus/wnbOm483bNx6fdIhgPhz+NkgAWmIBK+gdX+m1b8WclQDY
TFpdchsD/1lHTQqexciyCUDc+CvfyWIasAsiKf+oWhAIjvLNXu1bjQcZ1mr1cx+XGtPx
GGrteIenyw9woCws+B1w1p0NQTvMWVl5Uoybz840XOBPPlnYvbMCcsjrPwCwzXf8CjFW
7j8ri7p+PKX/6LsalQ62iuZ9ZLCKt9gvWgkCZOIexw4ZoP9GoOds6BdpuEfiav7HpXu6
R77UXvmXBYPl6egqP/3C5OMxjB8DCeKy3I+iamP2iMK0+VD6nRmPlvxO3+Aaj69l6aQy
mFCQ==
X-Gm-Message-State: AG10YOS7P3DgBpquPbsWm8fOour3mXb6kBZrqDLiOtLkl9fBUL5Zf1e33O/s6SwiYptdXk4MxGxEqvOq7dahJg==
MIME-Version: 1.0
X-Received: by 10.31.150.215 with SMTP id y206mr21813234vkd.63.1454461198298;
Tue, 02 Feb 2016 16:59:58 -0800 (PST)
Received: by 10.31.141.73 with HTTP; Tue, 2 Feb 2016 16:59:58 -0800 (PST)
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
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,RCVD_IN_DNSWL_LOW,URIBL_SBL autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP Process: Status, comments,
and copyright licenses
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Feb 2016 01:00:00 -0000
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
|
