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
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
|
Return-Path: <btcdrak@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1013F1E31
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Oct 2015 17:03:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com
[209.85.212.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2E6F41BE
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Oct 2015 17:03:26 +0000 (UTC)
Received: by wicge5 with SMTP id ge5so130021095wic.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 05 Oct 2015 10:03:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type;
bh=RLxf5gfBxb60YQ1IxZ6HAkidZS4Dn4Y36sbHcWtH6sQ=;
b=mKPXRm+y+yvd3Z0lpOV8jMbTcrWMKD6nxfDbTy6r9j7LB6gnJ0/uHa2eEl0KaRHcv+
SOjTb9c/t4Q9lgPUd+a0nwwbgHX55BZksf9SosOlC3ldLctwjQMfpDdajebDSV8XF3Yp
cmoKv1Oy47C/fz/kY1kJsQTpDEMF1DyoUkObsmSU+eEQdIrnxNQRUDs/psx1GxbNDPVm
kBE5Ww2JPup6c15AHXmWYS6Xjz3z1oZyDK2rIehGtQdZl/1QMBw1jnv5N9Zgmb0zeGsF
ZdjU7xwgGlPSVqONisGTM47/sOKgUogmdokkL1tZT5sBNvqJI5y7/bdmLkAbAqZf7I8p
XC7g==
X-Received: by 10.194.204.195 with SMTP id la3mr30454821wjc.77.1444064604897;
Mon, 05 Oct 2015 10:03:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.21.200 with HTTP; Mon, 5 Oct 2015 10:03:05 -0700 (PDT)
In-Reply-To: <CAKzdR-rPoByn=+CgsTc1ZnLkjwtYyJnbQLbn-VHOvz0dLciefQ@mail.gmail.com>
References: <CAKzdR-rPoByn=+CgsTc1ZnLkjwtYyJnbQLbn-VHOvz0dLciefQ@mail.gmail.com>
From: Btc Drak <btcdrak@gmail.com>
Date: Mon, 5 Oct 2015 18:03:05 +0100
Message-ID: <CADJgMzvMLTu8pmOVVJfg5xUWHMWiAcAUJXig2B=qX9Oimu+vGw@mail.gmail.com>
To: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bae4462cec6c405215e7d33
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HK_RANDOM_ENVFROM,
HK_RANDOM_FROM,
HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=no 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 17:03:27 -0000
--047d7bae4462cec6c405215e7d33
Content-Type: text/plain; charset=UTF-8
You are absolutely right and this is something I have often unsuccessfully
tried to explain as "disruption strategies". The problem is that most
people in the technical community assume good faith at all times, which
plays right into the frame required for disruption.
However, I would like to challenge your assumption of point 1 that that by
Mike making a rabble, it somehow makes CLTV deployment controversial. His
arguments have been refuted.
Mike has not presented anything convincing and history actually shows that
ISM works, and we have learned how to make it even more streamlined. We
know ISM has consensus because miners have accepted ISM for past softfork
rollouts.
Simply making a noise does not make something controversial. When it is
controversial, it is obvious and plain to see.
On Mon, Oct 5, 2015 at 4:56 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Some of the people on this mailing list are blindly discussing the
> technicalities of a soft/hard fork without realizing that is not Mike's
> main intention. At least I perceive (and maybe others too) something else
> is happening.
>
> Let me try to clarify: the discussion has nothing to do with technical
> arguments. I generally like more hard forks than soft forks (but I won't
> explain why because this is not a technical thread), but for CLTV this is
> quite irrelevant (but I won't explain why..), and I want CLTV to be
> deployed asap.
>
> Mike's intention is to criticize the informal governance model of Bitcoin
> Core development and he has strategically pushed the discussion to a
> dead-end where the group either:
>
> 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.
>
> As I don't want 2) to happen, then 1) must happen, which is what Mike
> wants. I have nothing for or against Mike personally. I just think Mike
> Hearn has won this battle. But having a more formal decision making process
> may not be too bad for Bitcoin, maybe it can actually be good.
>
> Best regards
> from a non-developer to my dearest developer friends,
> Sergio.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--047d7bae4462cec6c405215e7d33
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">You are absolutely right and this is something I have ofte=
n unsuccessfully tried to explain as "disruption strategies". The=
problem is that most people in the technical community assume good faith a=
t all times, which plays right into the frame required for disruption.<div>=
<br></div><div>However, I would like to challenge your assumption of point =
1 that that by Mike making a rabble, it somehow makes CLTV deployment contr=
oversial. His arguments have =C2=A0been refuted.</div><div><br></div><div>M=
ike has not presented anything convincing and history actually shows that I=
SM works, and we have learned how to make it even more streamlined. We know=
ISM has consensus because miners have accepted ISM for past softfork rollo=
uts.<br></div><div><br></div><div>Simply making a noise does not make somet=
hing controversial. When it is controversial, it is obvious and plain to se=
e.</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On =
Mon, Oct 5, 2015 at 4:56 PM, Sergio Demian Lerner via bitcoin-dev <span dir=
=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Some of the people on this=
mailing list are blindly discussing the technicalities of a soft/hard fork=
without realizing that is not Mike's main intention. At least I percei=
ve (and maybe others too) something else is happening.<div><br><div>Let me =
try to clarify: the discussion has nothing to do with technical arguments. =
I generally like more hard forks than soft forks (but I won't explain w=
hy because this is not a technical thread), but for CLTV this is quite irre=
levant (but I won't explain why..), and I want CLTV to be deployed asap=
.</div><div><br></div><div><div>Mike's intention is to criticize the in=
formal governance model of Bitcoin Core development and he has strategicall=
y pushed the discussion to a dead-end where the group either:</div><div><br=
></div><div>1) ignores him, which is against the established criteria that =
all technical objections coming from anyone must be addressed until that pe=
rson agrees, so that a change can be uncontroversial. If the group moves fo=
rward with the change, then the "uncontroversial" criteria is vio=
lated and then credibility is lost. So a new governance model would be requ=
ired for which the change is within the established rules.</div><div><br></=
div><div>2) respond to his technical objections one after the other, on nev=
er ending threads, bringing the project to a standstill.</div><div><br></di=
v><div>As I don't want 2) to happen, then 1) must happen, which is what=
Mike wants. I have nothing for or against Mike personally. I just think Mi=
ke Hearn has won this battle. But having a more formal decision making proc=
ess may not be too bad for Bitcoin, maybe it can actually be good.</div><di=
v><br></div><div>Best regards=C2=A0</div><div>=C2=A0from a non-developer to=
my dearest developer friends,</div><div>=C2=A0 Sergio.<br><div><br></div><=
/div></div></div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>
--047d7bae4462cec6c405215e7d33--
|
