From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2C956F2B for ; 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 ; Wed, 3 Feb 2016 00:59:59 +0000 (UTC) Received: by mail-vk0-f47.google.com with SMTP id e64so4000328vkg.0 for ; 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> <201602030003.33208.luke@dashjr.org> Date: Wed, 3 Feb 2016 01:59:58 +0100 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Luke Dashjr 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 [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 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 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