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
|
Return-Path: <not.mike.hearn@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id F27B7B1D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 2 Oct 2015 01:57:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f196.google.com (mail-io0-f196.google.com
[209.85.223.196])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6959B100
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 2 Oct 2015 01:57:39 +0000 (UTC)
Received: by ioii196 with SMTP id i196so9177941ioi.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 01 Oct 2015 18:57:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:date:message-id:subject:from:to:content-type;
bh=7alewBc+UyLVw+CJG0zkiwbdTrH5ZXCRtmO/lfxZYUU=;
b=OLTkKPRMFociTGXipWA8HnR1tZnuTMXpdpyBpInMxttDiNQ1Do+LviayZm7jnYOjv5
NuYEyrPVBsMSl3AFtcoLUK6ysOwjWsNhsHg7DI2htefhfzSe8nIEPgNFV1xhk+uAT4Ng
hl64YIel6Mm3DRIMVYzb36XXoEaPZzkZP6w7+eLKGncOjG4IoSFnXgum4ZhDBp3wNTL0
TGMVEhzM3XdUMv6l9XkKtSa3L/xqr2fOpA5kww9Y/d/g0XxMdUwhJ4Ytbb9Tfkjn2zEo
ykBQUSzfjfYiUHRxAAGBr2oAVxTZNbNOVOZyp7MWTwq5xPv8MlH3aFtgOhGvKeE0Vlvk
5z/Q==
MIME-Version: 1.0
X-Received: by 10.107.137.162 with SMTP id t34mr17012658ioi.103.1443751058819;
Thu, 01 Oct 2015 18:57:38 -0700 (PDT)
Received: by 10.64.223.164 with HTTP; Thu, 1 Oct 2015 18:57:38 -0700 (PDT)
Date: Thu, 1 Oct 2015 21:57:38 -0400
Message-ID: <CAKfs=Z_jVKtjeSHM1a6n+ch6WcazkshmDgN4Wi1K_kLBUE4o4w@mail.gmail.com>
From: NotMike Hearn <not.mike.hearn@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a113eacda016e640521157d72
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: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
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: Fri, 02 Oct 2015 01:57:40 -0000
--001a113eacda016e640521157d72
Content-Type: text/plain; charset=UTF-8
On 28 September 2015 at 06:48, Mike Hearn via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> There is no consensus on using a soft fork to deploy this feature. It will
> result in the same problems as all the other soft forks - SPV wallets will
> become less reliable during the rollout period. I am against that, as it's
> entirely avoidable.
>
> Make it a hard fork and my objection will be dropped.
>
> Until then, as there is no consensus, you need to do one of two things:
>
> 1) Drop the "everyone must agree to make changes" idea that people here
like
> to peddle, and do it loudly, so everyone in the community is correctly
> informed
>
> 2) Do nothing
>
>
I agree with Mike Hearn that there is no consensus on using a soft fork to
deploy this feature. Either everyone agrees that we should all agree on
consensus or else there is arbitrary disagreement. You cannot have it both
ways.
It is very important that we reach consensus on consensus or, if you will,
meta0consensus. I think we should Do nothing as that is clearly the choice
that we have taken re: blocksize. If we use one set of rules for that
decision we should use the same set of rules for all decisions and there is
no middle ground.
Thank you.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a113eacda016e640521157d72
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>On 28 September 2015 at 06:48, Mike Hearn via bitcoin=
-dev</div><div><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
>bitcoin-dev@lists.linuxfoundation.org</a>> wrote:</div><div>> There =
is no consensus on using a soft fork to deploy this feature. It will</div><=
div>> result in the same problems as all the other soft forks - SPV wall=
ets will</div><div>> become less reliable during the rollout period. I a=
m against that, as it's</div><div>> entirely avoidable.</div><div>&g=
t;</div><div>> Make it a hard fork and my objection will be dropped.</di=
v><div>></div><div>> Until then, as there is no consensus, you need t=
o do one of two things:</div><div>></div><div>> 1) Drop the "eve=
ryone must agree to make changes" idea that people here like</div><div=
>> to peddle, and do it loudly, so everyone in the community is correctl=
y</div><div>> informed</div><div>></div><div>> 2) Do nothing</div>=
<div>></div><div>></div><div><br></div><div>I agree with Mike Hearn t=
hat there is no consensus on using a soft fork to deploy this feature. Eith=
er everyone agrees that we should all agree on consensus or else there is a=
rbitrary disagreement. You cannot have it both ways.<br><br>It is very impo=
rtant that we reach consensus on consensus or, if you will, meta0consensus.=
I think we should Do nothing as that is clearly the choice that we have ta=
ken re: blocksize. If we use one set of rules for that decision we should u=
se the same set of rules for all decisions and there is no middle ground.</=
div><div><br>Thank you.</div><div><br></div><div>></div><div>> ______=
_________________________________________</div><div>> bitcoin-dev mailin=
g list</div><div>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o=
rg">bitcoin-dev@lists.linuxfoundation.org</a></div><div>> <a href=3D"htt=
ps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.=
linuxfoundation.org/mailman/listinfo/bitcoin-dev</a></div><div>></div><d=
iv><br></div></div>
--001a113eacda016e640521157d72--
|
