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
|
Return-Path: <sergio.d.lerner@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D087311CE
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Oct 2015 15:57:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com
[209.85.218.45])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6700C1A0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 5 Oct 2015 15:57:13 +0000 (UTC)
Received: by oiev17 with SMTP id v17so93072672oie.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 05 Oct 2015 08:57:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:from:date:message-id:subject:to:content-type;
bh=VrO+1iSrIf3je8PspWdwRDiWChIKxJHfLPlj2EQ4nBM=;
b=M3Cf+c15NDK8rIMAhWZN6xKFiwYSZyRE0n40BXFlbo0XC1YuEgxuSYULH6zOnwyfrA
9XFE5AWwpffwzYSrS9D1ZFQsRuvDQOo1LDiXFdoUXtofWlGzq/jpcQELMWGmUxcYWg2N
Wqs+GUcNxEKvQaUwuhgSIcxD3LKUlAR+BiP4IHx0yNqYpfmM2kTmekYFMOvKqQArx98S
GMXg1rOk6PNNWWpkjB7uOrayyvCz5wMcKIXJ8L8KXiEeUIFyi39r3i87ezMe9KdQCKvp
ecSWlFXCO80oufnuC9lQAwGYtoy8czTCOSJCqCR3/T82PSYbHY+l5ZdKesOSx4v7cslk
Dpcw==
X-Received: by 10.202.93.70 with SMTP id r67mr16681568oib.89.1444060632775;
Mon, 05 Oct 2015 08:57:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.197.82 with HTTP; Mon, 5 Oct 2015 08:56:33 -0700 (PDT)
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Mon, 5 Oct 2015 12:56:33 -0300
Message-ID: <CAKzdR-rPoByn=+CgsTc1ZnLkjwtYyJnbQLbn-VHOvz0dLciefQ@mail.gmail.com>
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113d59aa0d04bf05215d913a
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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
Subject: [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 15:57:13 -0000
--001a113d59aa0d04bf05215d913a
Content-Type: text/plain; charset=UTF-8
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.
--001a113d59aa0d04bf05215d913a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Some of the people on this mailing list are blindly discus=
sing the technicalities of a soft/hard fork without realizing that is not M=
ike's main intention. At least I perceive (and maybe others too) someth=
ing else is happening.<div><br><div>Let me try to clarify: the discussion h=
as 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 technic=
al thread), but for CLTV this is quite irrelevant (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 informal governance model of Bitco=
in Core development and he has strategically pushed the discussion to a dea=
d-end where the group either:</div><div><br></div><div>1) ignores him, whic=
h is against the established criteria that all technical objections coming =
from anyone must be addressed until that person agrees, so that a change ca=
n be uncontroversial. If the group moves forward with the change, then the =
"uncontroversial" criteria is violated and then credibility is lo=
st. So a new governance model would be required for which the change is wit=
hin the established rules.</div><div><br></div><div>2) respond to his techn=
ical objections one after the other, on never ending threads, bringing the =
project to a standstill.</div><div><br></div><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 Mike Hearn has won this battle. Bu=
t having a more formal decision making process may not be too bad for Bitco=
in, maybe it can actually be good.</div><div><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>
--001a113d59aa0d04bf05215d913a--
|
