summaryrefslogtreecommitdiff
path: root/ad/6b11e55fc8c588abc5aaed09bdc73275868f16
blob: a1696d85190c0a122e0821d96ec2bd09fb537e9f (plain)
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
Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 11E77273
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 25 Jun 2015 23:52:16 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com
	[209.85.217.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2DC9E7C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 25 Jun 2015 23:52:15 +0000 (UTC)
Received: by lbbpo10 with SMTP id po10so54813509lbb.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 25 Jun 2015 16:52:13 -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:to
	:cc:content-type;
	bh=z8QpoZZrfPDOovpDruue2zz+zOoVJNMiajqPbJ9JEzw=;
	b=frH9NEtQ5nGdA2W6Wz0TW/k5TVC82uCF6daSHaWquAQfb1NYJA5XXkAsOAHTjWAU5u
	MUgNialKg8JCZNWnfDs/dRxr7M+YOqPQ/S10yHdFKyLGpG95IiG66XFq2v2Fa3V+A+oP
	tgM1i0EZZH+IGTtTdlL2qFEAKBjv41198zJpdsFGI2ueXBBr2PZKGFadTp0R+7Y3r15O
	gl59SEcAfiC1VX10xIB2J2M5RotnwQsJng+ydFKIQRfhHBBXqRUct7Ad72unE40Exj6N
	A9rEDtDHyIBWFtdJJsm/1SJHOwajBB8pELo8Yc3oCBaWOT2XtdIzL900OFD8dw3KAA1o
	T9aw==
MIME-Version: 1.0
X-Received: by 10.152.4.163 with SMTP id l3mr14494471lal.35.1435276333138;
	Thu, 25 Jun 2015 16:52:13 -0700 (PDT)
Received: by 10.112.53.5 with HTTP; Thu, 25 Jun 2015 16:52:12 -0700 (PDT)
Received: by 10.112.53.5 with HTTP; Thu, 25 Jun 2015 16:52:12 -0700 (PDT)
In-Reply-To: <20150625223344.GA2406@muck>
References: <20150625223344.GA2406@muck>
Date: Thu, 25 Jun 2015 16:52:12 -0700
Message-ID: <CABr1YTf20qzXmaLepnsCjAjwMY6x69C_KXcMgdcwqctWY9+_Gg@mail.gmail.com>
From: Eric Lombrozo <elombrozo@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=089e013d100cfdcb2e0519604f30
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
Cc: bitcoin-dev@lists.linuxfoundation.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: Thu, 25 Jun 2015 23:52:16 -0000

--089e013d100cfdcb2e0519604f30
Content-Type: text/plain; charset=UTF-8

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
>
>

--089e013d100cfdcb2e0519604f30
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Please do it.</p>
<div class=3D"gmail_quote">On Jun 25, 2015 3:33 PM, &quot;Peter Todd&quot; =
&lt;<a href=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>&gt; wrote:=
<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">BIP66 adoption is q=
uite 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&#39;m both a fan and co-author of the Version bits BIP(1) proposal,=
<br>
it hasn&#39;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&#39;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 &quot;mempool-only&quot; 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&#39;s also been famously=
<br>
described as &quot;What you thought nLockTime did until you actually tried =
to<br>
use it.&quot;<br>
<br>
To that end I&#39;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 &quot;in-flight&quot; at the same time.<br>
<br>
Thoughts? If there are no objections I&#39;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>
&#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org" rel=3D"noreferrer" ta=
rget=3D"_blank">petertodd.org</a><br>
0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24<br>
<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>

--089e013d100cfdcb2e0519604f30--