diff options
author | Gregory Maxwell <gmaxwell@gmail.com> | 2015-10-05 18:35:13 +0000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-10-05 18:35:15 +0000 |
commit | fa1a6683403dd2239b41181e9caff77650d134f4 (patch) | |
tree | 0723523a7f13714d3566ef1436421b3f985be1d3 /27 | |
parent | 68c4675cc54367c88a2339cbbc43ce7fbd782661 (diff) | |
download | pi-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/b9368263568e17ab24c612d8e36ff52a40f643 | 112 |
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. + |