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
|
Return-Path: <slashdevnull@hotmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6A7D41BA1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 2 Oct 2015 02:10:50 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from BLU004-OMC4S18.hotmail.com (blu004-omc4s18.hotmail.com
[65.55.111.157])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0178420C
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 2 Oct 2015 02:10:48 +0000 (UTC)
Received: from BLU436-SMTP132 ([65.55.111.137]) by BLU004-OMC4S18.hotmail.com
over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008);
Thu, 1 Oct 2015 19:10:48 -0700
X-TMN: [FwDfxp9z7t8BN3zElT1CATQ793kGLHQZ]
X-Originating-Email: [slashdevnull@hotmail.com]
Message-ID: <BLU436-SMTP132FA09C343ACB7C82E6C98C64B0@phx.gbl>
User-Agent: Microsoft-MacOutlook/14.4.9.150325
Date: Fri, 2 Oct 2015 10:12:58 +0800
From: GC <slashdevnull@hotmail.com>
To: NotMike Hearn <not.mike.hearn@gmail.com>,
<bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
References: <CAKfs=Z_jVKtjeSHM1a6n+ch6WcazkshmDgN4Wi1K_kLBUE4o4w@mail.gmail.com>
In-Reply-To: <CAKfs=Z_jVKtjeSHM1a6n+ch6WcazkshmDgN4Wi1K_kLBUE4o4w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="B_3526625586_4125295"
X-OriginalArrivalTime: 02 Oct 2015 02:10:47.0237 (UTC)
FILETIME=[8D3A5750:01D0FCB7]
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
HTML_MESSAGE,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_LOW,T_RP_MATCHES_RCVD
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 02:10:50 -0000
--B_3526625586_4125295
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Or, you know, enter some discussions on what exactly are the issues that SP=
V
clients face during soft forks and see if anything can be done (on all
sides) to mitigate the risks.
Crazy stuff, I know =8A ;-)
From: NotMike Hearn via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org=
>
Reply-To: NotMike Hearn <not.mike.hearn@gmail.com>
Date: Friday, 2 October 2015 9:57 am
To: <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
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 wil=
l
> result in the same problems as all the other soft forks - SPV wallets wil=
l
> 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 l=
ike
> 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
>
_______________________________________________ bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--B_3526625586_4125295
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
<html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size:=
14px; font-family: Calibri, sans-serif;"><div>Or, you know, enter some disc=
ussions on what exactly are the issues that SPV clients face during soft for=
ks and see if anything can be done (on all sides) to mitigate the risks.</di=
v><div><br></div><div>Crazy stuff, I know … ;-)</div><div><br></div><s=
pan id=3D"OLK_SRC_BODY_SECTION"><div style=3D"font-family:Calibri; font-size:11p=
t; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: me=
dium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDE=
R-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span=
style=3D"font-weight:bold">From: </span> NotMike Hearn via bitcoin-dev <<a=
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linux=
foundation.org</a>><br><span style=3D"font-weight:bold">Reply-To: </span> N=
otMike Hearn <<a href=3D"mailto:not.mike.hearn@gmail.com">not.mike.hearn@gm=
ail.com</a>><br><span style=3D"font-weight:bold">Date: </span> Friday, 2 Oc=
tober 2015 9:57 am<br><span style=3D"font-weight:bold">To: </span> <<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfound=
ation.org</a>><br><span style=3D"font-weight:bold">Subject: </span> Re: [bi=
tcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!<br></div><div><br></div><=
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">bitcoi=
n-dev@lists.linuxfoundation.org</a>> wrote:</div><div>> There is no co=
nsensus 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 wallets will</=
div><div>> become less reliable during the rollout period. I am against t=
hat, as it's</div><div>> entirely avoidable.</div><div>></div><div>>=
; Make it a hard fork and my objection will be dropped.</div><div>></div>=
<div>> Until then, as there is no consensus, you need to do one of two th=
ings:</div><div>></div><div>> 1) Drop the "everyone must agree to make=
changes" idea that people here like</div><div>> to peddle, and do it lou=
dly, so everyone in the community is correctly</div><div>> informed</div>=
<div>></div><div>> 2) Do nothing</div><div>></div><div>></div><d=
iv><br></div><div>I agree with Mike Hearn that there is no consensus on usin=
g 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 h=
ave it both ways.<br><br>It is very important that we reach consensus on con=
sensus 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 o=
f rules for that decision we should use the same set of rules for all decisi=
ons and there is no middle ground.</div><div><br>Thank you.</div><div><br></=
div><div>></div><div>> _______________________________________________=
</div><div>> bitcoin-dev mailing list</div><div>> <a href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>=
</div><div>> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/=
bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/a></div><div>></div><div><br></div></div>
_______________________________________________
bitcoin-dev mailing list
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li=
nuxfoundation.org</a>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">ht=
tps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</span></body></html>
--B_3526625586_4125295--
|
