summaryrefslogtreecommitdiff
path: root/27
diff options
context:
space:
mode:
authorGregory Maxwell <gmaxwell@gmail.com>2015-10-05 18:35:13 +0000
committerbitcoindev <bitcoindev@gnusha.org>2015-10-05 18:35:15 +0000
commitfa1a6683403dd2239b41181e9caff77650d134f4 (patch)
tree0723523a7f13714d3566ef1436421b3f985be1d3 /27
parent68c4675cc54367c88a2339cbbc43ce7fbd782661 (diff)
downloadpi-bitcoindev-fa1a6683403dd2239b41181e9caff77650d134f4.tar.gz
pi-bitcoindev-fa1a6683403dd2239b41181e9caff77650d134f4.zip
Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate
Diffstat (limited to '27')
-rw-r--r--27/b9368263568e17ab24c612d8e36ff52a40f643112
1 files changed, 112 insertions, 0 deletions
diff --git a/27/b9368263568e17ab24c612d8e36ff52a40f643 b/27/b9368263568e17ab24c612d8e36ff52a40f643
new file mode 100644
index 000000000..45c51bfe0
--- /dev/null
+++ b/27/b9368263568e17ab24c612d8e36ff52a40f643
@@ -0,0 +1,112 @@
+Return-Path: <gmaxwell@gmail.com>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+ [172.17.192.35])
+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 235B71A38
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Mon, 5 Oct 2015 18:35:15 +0000 (UTC)
+X-Greylist: whitelisted by SQLgrey-1.7.6
+Received: from mail-ig0-f195.google.com (mail-ig0-f195.google.com
+ [209.85.213.195])
+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8A2FA13C
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Mon, 5 Oct 2015 18:35:14 +0000 (UTC)
+Received: by igbbp9 with SMTP id bp9so10799698igb.0
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Mon, 05 Oct 2015 11:35:13 -0700 (PDT)
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
+ h=mime-version:in-reply-to:references:date:message-id:subject:from:to
+ :cc:content-type;
+ bh=a2fFXhlfUKlFStjK2DEikmmxuCy7YjS7vdSm37uIDB8=;
+ b=e4yjWVXSlP85m5LvMVHEWMVNnLsakMlj6HUaCssknjlhKNzhr2sdCykqtzyhnCZTn8
+ x+rhJd1TTI2x6TVnwx1sArz2fwwUkX+SRfgh1v1vhO7WO9uzuTtmBFhkjymQ2GEDsvRV
+ Aty4xyBmiqtrUFlNDf77o6JpTDrsh0hyfW8/+2vqZb0nIJ6DqCJ47QlutNx/dvXX0eUq
+ 18zhamFID1eYFdXxigrgKzQSAEfBMoT4fTsYvGcagatEbJvxaaUUXWH9aEG/0Jybwlgu
+ 3WvH+jDngAO/zevWtBfVdz6GjWQz//M17Fhlp3j//AEMElpQLdAyOFUumROADBffFGCk
+ g0Sw==
+MIME-Version: 1.0
+X-Received: by 10.50.50.173 with SMTP id d13mr10205497igo.66.1444070113862;
+ Mon, 05 Oct 2015 11:35:13 -0700 (PDT)
+Received: by 10.107.19.30 with HTTP; Mon, 5 Oct 2015 11:35:13 -0700 (PDT)
+In-Reply-To: <CAKzdR-rPoByn=+CgsTc1ZnLkjwtYyJnbQLbn-VHOvz0dLciefQ@mail.gmail.com>
+References: <CAKzdR-rPoByn=+CgsTc1ZnLkjwtYyJnbQLbn-VHOvz0dLciefQ@mail.gmail.com>
+Date: Mon, 5 Oct 2015 18:35:13 +0000
+Message-ID: <CAAS2fgQ3Qs=s7qwhxjwJa9cLJLMJg+LXjPQDCGUDMEjyrHqO_A@mail.gmail.com>
+From: Gregory Maxwell <gmaxwell@gmail.com>
+To: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
+Content-Type: text/plain; charset=UTF-8
+X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
+ DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
+ RCVD_IN_DNSWL_LOW 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] This thread is not about the soft/hard fork
+ technical debate
+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: Mon, 05 Oct 2015 18:35:15 -0000
+
+On Mon, Oct 5, 2015 at 3:56 PM, Sergio Demian Lerner via bitcoin-dev
+<bitcoin-dev@lists.linuxfoundation.org> wrote:
+> 1) ignores him, which is against the established criteria that all technical
+> objections coming from anyone must be addressed until that person agrees, so
+> that a change can be uncontroversial. If the group moves forward with the
+> change, then the "uncontroversial" criteria is violated and then credibility
+> is lost. So a new governance model would be required for which the change is
+> within the established rules.
+>
+> 2) respond to his technical objections one after the other, on never ending
+> threads, bringing the project to a standstill.
+
+I don't agree-- I think you've made the mistake of just accepting the
+particular framing that Mike has provide; one that (no shock) only
+supports his conclusions.
+
+I am aware of no instance where an active contributor to core has made
+the claim that no change to consensus can happen without 100% support
+(and doubly so, 100% including people who are expressly trying to
+disrupt the project by posing opposition which, as you note, is
+largely unrelated to the merits of the proposals). Mike has lead you
+to believe people have claimed this, but no one has-- it's a view
+which is simple, clear, and completely not reflecting reality. Don't
+fall for strawman arguments.
+
+In this situation it is also a particularly strong apples/oranges comparison:
+
+Soft forks can happen at any time at the whim of miners-- no
+technology which we are aware of (beyond the technology of
+centralization) is able to prevent them-- they are not necessarily
+even detectable; on this basis they are categorically different than
+hard forks.
+
+Moreover, the space of soft-forks the contributors to Bitcoin Core
+would ever consider is a tiny space of all possible soft-forks, and
+are ones which cannot be rationally understood to meaningfully
+undermine the properties provided by the rules enforced within the
+software; again making them different from some other proposals and of
+a lesser concern.
+
+Finally, the behavior of the technology arising from the inherent
+compatibility, radically lowers (in most of our experience and
+opinion) the cost of deployment; again-- making them different. They
+prevent a industry wide flag day, and tight release synchronization
+which is harmful to decentralization promoting software diversity.
+
+As I think I commented in one of my messages-- I respond to the
+technical arguments not because I believe they are earnestly
+motivated, but because they provide an avenue for learning for myself
+and others. Even someone trying to disrupt the process and nothing
+else can help us learn by acting as an adversary that causes us to
+extend our minds and understanding. The process for CLTV has been
+ongoing for something like a year and a half and has little risk of
+being substantially disrupted at this point.
+