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
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BCBF8AE7
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Jun 2015 00:07:49 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com
[209.85.220.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D9F19140
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Jun 2015 00:07:48 +0000 (UTC)
Received: by qkbp125 with SMTP id p125so47235055qkb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Jun 2015 17:07:48 -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:cc
:content-type; bh=Vx3xr+fZsIrg/7auKrLufLh/ZLSCjCblr3Ym57ptR7Q=;
b=tx0ekBL1CB0616pHU5UPHWHB/LQogoAOedVIGpHaz9i1nn2hbutoh85ICP0I+/H6f/
7K+uXZUmcqtQywCKFqr4yQMcWFV+eU5LGmo2KPsKelDwR24xjj51QN5M9OazqqJwybAD
mXLnCI2ba8b1/ME9QqlQt1ust1UKZsYXOtt/Qj8rgAXpA2tQnez8aW5iBZqDKCIa2Yjx
y7hAsrIon+gctu6u+bc0ut6Dbj7KFpyOdW23445rSPhiaMfP2QXQ3aMmeYcFN8DqZeRY
NfqJYIKV3+y4agDYwK5h8eVDPAM7QodASIRZqMzi2zuBgg8aStXcHsZV+vlwXUazrVN5
NDxA==
MIME-Version: 1.0
X-Received: by 10.55.16.83 with SMTP id a80mr85442748qkh.63.1435277268119;
Thu, 25 Jun 2015 17:07:48 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Thu, 25 Jun 2015 17:07:48 -0700 (PDT)
In-Reply-To: <CABr1YTf20qzXmaLepnsCjAjwMY6x69C_KXcMgdcwqctWY9+_Gg@mail.gmail.com>
References: <20150625223344.GA2406@muck>
<CABr1YTf20qzXmaLepnsCjAjwMY6x69C_KXcMgdcwqctWY9+_Gg@mail.gmail.com>
Date: Fri, 26 Jun 2015 01:07:48 +0100
Message-ID: <CAE-z3OWq_8r52yy2-FDGtZUZhRCDQRs8-ACSEKZ=HXj5ZRk-5w@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a1146922ab874e605196087b9
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS,
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
Subject: Re: [bitcoin-dev] BIP65 / CHECKLOCKTIMEVERIFY deployment
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, 26 Jun 2015 00:07:49 -0000
--001a1146922ab874e605196087b9
Content-Type: text/plain; charset=UTF-8
It would be possible to run a simplified version of the bits proposal,
until BIP 66 locks.
It's obviously not worth it at this point though, though it could be 1-2
weeks more.
Version 2 means neither option
Version 3 means BIP 66 only
Version 4 means CLTV only
Version 5 means both
If (Version 3 + version 5) > 95%, reject 2 & 4
If (Version 4 + version 5) > 95%, reject 2 & 3
For 2 options at the same time, this isn't much extra overhead.
On Fri, Jun 26, 2015 at 12:52 AM, Eric Lombrozo <elombrozo@gmail.com> wrote:
> Please do it.
> On Jun 25, 2015 3:33 PM, "Peter Todd" <pete@petertodd.org> wrote:
>
>> BIP66 adoption is quite close to 95% and will likely be enforced for all
>> blocks in a few more days; now is time to think about how CLTV will be
>> deployed, particularly given its benefits to much-needed scalability
>> solutions such as payment channels.
>>
>> While I'm both a fan and co-author of the Version bits BIP(1) proposal,
>> it hasn't been implemented yet, and the implementation will be
>> relatively complex compared to the previous soft-fork mechanism. I think
>> there is good reason to get CLTV deployed sooner, and I don't think we
>> have any lack of consensus on it. The CLTV code itself has been
>> extensively reviewed in the form of the "mempool-only" pull-req, has
>> been included in the Elements sidechain prototype by Mark Friedenbach,
>> has been running in production on Viacoin for six months, and has a few
>> working demos of its functionality implemented. It's also been famously
>> described as "What you thought nLockTime did until you actually tried to
>> use it."
>>
>> To that end I'm proposing that we simply use the existing median block
>> version mechanism previously used for the nVersion=2 and nVersion=3
>> soft-forks for CLTV. This mechanism is well-tested and understood, and
>> would allow CLTV to be easily backported to v0.10.x (even 0.9.x) with
>> little risk for rapid deployment. In the event that another soft-fork is
>> proposed prior to BIP65, nVersion=4, enforcement, we do have the option
>> of setting in motion yet another soft-fork as the median mechanism only
>> requires forks to be serialized in sequence - it does not prevent
>> multiple soft-forks from being "in-flight" at the same time.
>>
>> Thoughts? If there are no objections I'll go ahead and write that code,
>> using the same thresholds as BIP66.
>>
>> 1)
>> https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07863.html
>>
>> --
>> 'peter'[:-1]@petertodd.org
>> 0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24
>>
>> _______________________________________________
>> 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
>
>
--001a1146922ab874e605196087b9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div><div><div><div></div>It would be =
possible to run a simplified version of the bits proposal, until BIP 66 loc=
ks.=C2=A0 <br><br>It's obviously not worth it at this point though, tho=
ugh it could be 1-2 weeks more.=C2=A0 <br></div><div><br></div>Version 2 me=
ans neither option<br></div>Version 3 means BIP 66 only<br></div>Version 4 =
means CLTV only<br></div>Version 5 means both<br><br></div>If (Version 3 + =
version 5) > 95%, reject 2 & 4<br>If (Version 4 + version 5) > 95=
%, reject 2 & 3<br><br></div>For 2 options at the same time, this isn&#=
39;t much extra overhead.<br></div><div><div><div><div><br></div></div></di=
v></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On =
Fri, Jun 26, 2015 at 12:52 AM, Eric Lombrozo <span dir=3D"ltr"><<a href=
=3D"mailto:elombrozo@gmail.com" target=3D"_blank">elombrozo@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">Please do=
it.</p>
<div class=3D"gmail_quote"><div><div class=3D"h5">On Jun 25, 2015 3:33 PM, =
"Peter Todd" <<a href=3D"mailto:pete@petertodd.org" target=3D"=
_blank">pete@petertodd.org</a>> wrote:<br type=3D"attribution"></div></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5">BIP66 adoption is =
quite close to 95% and will likely be enforced for all<br>
blocks in a few more days; now is time to think about how CLTV will be<br>
deployed, particularly given its benefits to much-needed scalability<br>
solutions such as payment channels.<br>
<br>
While I'm both a fan and co-author of the Version bits BIP(1) proposal,=
<br>
it hasn't been implemented yet, and the implementation will be<br>
relatively complex compared to the previous soft-fork mechanism. I think<br=
>
there is good reason to get CLTV deployed sooner, and I don't think we<=
br>
have any lack of consensus on it. The CLTV code itself has been<br>
extensively reviewed in the form of the "mempool-only" pull-req, =
has<br>
been included in the Elements sidechain prototype by Mark Friedenbach,<br>
has been running in production on Viacoin for six months, and has a few<br>
working demos of its functionality implemented. It's also been famously=
<br>
described as "What you thought nLockTime did until you actually tried =
to<br>
use it."<br>
<br>
To that end I'm proposing that we simply use the existing median block<=
br>
version mechanism previously used for the nVersion=3D2 and nVersion=3D3<br>
soft-forks for CLTV. This mechanism is well-tested and understood, and<br>
would allow CLTV to be easily backported to v0.10.x (even 0.9.x) with<br>
little risk for rapid deployment. In the event that another soft-fork is<br=
>
proposed prior to BIP65, nVersion=3D4, enforcement, we do have the option<b=
r>
of setting in motion yet another soft-fork as the median mechanism only<br>
requires forks to be serialized in sequence - it does not prevent<br>
multiple soft-forks from being "in-flight" at the same time.<br>
<br>
Thoughts? If there are no objections I'll go ahead and write that code,=
<br>
using the same thresholds as BIP66.<br>
<br>
1) <a href=3D"https://www.mail-archive.com/bitcoin-development@lists.source=
forge.net/msg07863.html" rel=3D"noreferrer" target=3D"_blank">https://www.m=
ail-archive.com/bitcoin-development@lists.sourceforge.net/msg07863.html</a>=
<br>
<br>
--<br>
'peter'[:-1]@<a href=3D"http://petertodd.org" rel=3D"noreferrer" ta=
rget=3D"_blank">petertodd.org</a><br>
0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24<br>
<br></div></div>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
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>_______________________________________________<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>
--001a1146922ab874e605196087b9--
|
