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
|
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.
|
