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
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
|
Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C4A21125C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Sep 2015 20:28:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f176.google.com (mail-io0-f176.google.com
[209.85.223.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 31297188
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Sep 2015 20:28:17 +0000 (UTC)
Received: by iofb144 with SMTP id b144so157080314iof.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Sep 2015 13:28:16 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-type;
bh=PxqfZgVrcQv4pyoQEQUR8ATWU2hOJjj4T0bQAZybitE=;
b=MDOeCs5Sag9aHeaEzb4o2QSqTUTckGcV0bjZUEOqZ+L4oNCdDwav4E1eNJxf0Zq7Y0
uqJcOiSjr+P0NyuUMKM+5BVLoCLL0AZGxEn3Z0w3u6/jZp2rzq5h2s9ChwuPKaWtNPQI
Gn0Dnf9kpQvypGaT22EbaHrk6ed2dMCe0c3EjDxxt93M1OddO+GR13i9pCx9FeX7XG8E
9j1RkhBHHacLa47ZMnJDUJMVak1b/8Sg7wwVqsFCYez7FzIjuL24b1wjbZxNpax9zYPO
rg0hs3jB8nPOPiNbrwa5r+q9n8xidJZwIQQpsHUoodRgWJfSdfTTeDasvltHKKhcURsI
XEZA==
X-Gm-Message-State: ALoCoQlbmBIfTnkUZpQO46ktcorDxKtpYik/x+C1zYeX8mExXbrNVEq6Ateu15V3Zsc5Y/N7EooF
X-Received: by 10.107.11.154 with SMTP id 26mr17912419iol.105.1443385696626;
Sun, 27 Sep 2015 13:28:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.135.104 with HTTP; Sun, 27 Sep 2015 13:27:57 -0700 (PDT)
X-Originating-IP: [173.228.107.141]
In-Reply-To: <20150927185031.GA20599@savin.petertodd.org>
References: <20150927185031.GA20599@savin.petertodd.org>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Sun, 27 Sep 2015 13:27:57 -0700
Message-ID: <CAOG=w-ssCBOceBz-kMdFLhu5-nqssHic5yAbvMN1kq-nZTGfJQ@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a113f7e7cb8e1e90520c06bd8
X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
RCVD_IN_DNSWL_LOW,UC_GIBBERISH_OBFU autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.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: Sun, 27 Sep 2015 20:28:18 -0000
--001a113f7e7cb8e1e90520c06bd8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Agree with all CLTV and nVersionBits points. We should deploy a lock-time
soft-fork ASAP, using the tried and true IsSuperMajoirty test.
However your information regarding BIPs 68 (sequence numbers), 112
(checksequenceverify) and 113 (median time past) is outdated. Debate
regarding semantics has been settled, and there are working implementations
ready for merge on github. See pull requests #6312, #6564, and #6566. I
don=E2=80=99t know what the hold up has been regarding further reviews and =
merging,
but it is ready.
If you believe there are reasons #6312, #6564, or #6566 should not be
merged, please speak up. Otherwise it appears there is consensus on these
changes. They are related, and there is no reason not to include them in
the soft-fork, delaying applications using these features by 6-12 months.
On Sun, Sep 27, 2015 at 11:50 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Summary
> -------
>
> It's time to deploy BIP65 CHECKLOCKTIMEVERIFY.
>
> I've backported the CLTV op-code and a IsSuperMajority() soft-fork to
> the v0.10 and v0.11 branches, pull-reqs #6706 and #6707 respectively. A
> pull-req for git HEAD for the soft-fork deployment has been open since
> June 28th, #6351 - the opcode implementation itself was merged two
> months ago.
>
> We should release a v0.10.3 and v0.11.1 with CLTV and get the ball
> rolling on miner adoption. We have consensus that we need CLTV, we have
> a well tested implementation, and we have a well-tested deployment
> mechanism. We also don't need to wait for other soft-fork proposals to
> catch up - starting the CLTV deployment process isn't going to delay
> future soft-forks, or for that matter, hard-forks.
>
> I think it's possible to safely get CLTV live on mainnet before the end
> of the year. It's time we get this over with and done.
>
>
> Detailed Rational
> -----------------
>
> 1) There is a clear need for CLTV
>
> Escrow and payment channels both benefit greatly from CLTV. In
> particular, payment channel implementations are made significantly
> simpler with CLTV, as well as more secure by removing the malleability
> vulnerability.
>
> Why are payment channels important? There's a lot of BTC out there
> vulnerable to theft that doesn't have to be. For example, just the other
> day I was talking with Nick Sullivan about ChangeTip's vulnerability to
> theft, as well as regulatory uncertainty about whether or not they're a
> custodian of their users' funds. With payment channels ChangeTip would
> only be able to spend as much of a deposit as a user had spent, keeping
> the rest safe from theft. Similarly, in the other direction - ChangeTip
> to their users - in many cases it is feasible to also use payment
> channels to immediately give users control of their funds as they
> receive them, again protecting users and helping make the case that
> they're not a custodian. In the future I'm sure we'll see fancy
> bi-directional payment channels serving this role, but lets not let
> perfect be the enemy of good.
>
>
> 2) We have consensus on the semantics of the CLTV opcode
>
> Pull-req #6124 - the implementation of the opcode itself - was merged
> nearly three months ago after significant peer review and discussion.
> Part of that review process included myself(1) and mruddy(2) writing
> actual demos of CLTV. The chance of the CLTV semantics changing now is
> near-zero.
>
>
> 3) We have consensus that Bitcoin should adopt CLTV
>
> The broad peer review and discussion that got #6124 merged is a clear
> sign that we expect CLTV to be eventually adopted. The question isn't if
> CLTV should be added to the Bitcoin protocol, but rather when.
>
>
> 4) The CLTV opcode and IsSuperMajority() deployment code has been
> thoroughly tested and reviewed
>
> The opcode implementation is very simple, yet got significant review,
> and it has solid test coverage by a suite of tx-(in)valid.json tests.
> The tests themselves have been reviewed by others, resulting in Esteban
> Ordano's pull-req #6368 by Esteban Ordano which added a few more cases.
>
> As for the deployment code, both the actual IsSuperMajority() deployment
> code and associated unit-tests tests were copied nearly line-by-line
> from the succesful BIP66. I did this deliberately to make all the peer
> review and testing of the deployment mechanism used in BIP66 be equally
> valid for CLTV.
>
>
> 5) We can safely deploy CLTV with IsSuperMajority()
>
> We've done two soft-forks so far with the IsSuperMajority() mechanism,
> BIP34 and BIP66. In both cases the IsSuperMajority() mechanism itself
> worked flawlessly. As is well-known BIP66 in combination with a large %
> of the hashing power running non-validating "SPV" mining operations did
> lead to a temporary fork, however the root cause of this issue is
> unavoidable and not unique to IsSuperMajority() soft-forks.
>
> Pragmatically speaking, now that miners are well aware of the issue it
> will be easy for them to avoid a repeat of that fork by simply adding
> IsSuperMajority() rules to their "SPV" mining code. Equally turning off
> SPV mining (temporarily) is perfectly feasable.
>
>
> 6) We have the necessary consensus to deploy CLTV via IsSuperMajority()
>
> The various "nVersion bits" proposals - which I am a co-author of - have
> the primary advantage of being able to cleanly deal with the case where
> a soft-fork fails to get adopted. However, we do have broad consensus,
> including across all sides of the blocksize debate, that CLTV should be
> adopted. The risk of CLTV failing to get miner adoption, and thus
> blocking other soft-forks, is very low.
>
>
> 7) Using IsSuperMajority() to deploy CLTV doesn't limit or delay other
> upgrades
>
> It _is_ possible for multiple IsSuperMajority() soft-forks to coexist,
> in the sense that if one soft-fork is "in flight" that doesn't prevent
> another soft-fork from also being deployed simultaneously.
>
> In particular, if we deploy CLTV via IsSuperMajority() that does _not_
> impact the adoption schedule for other future soft-forks, including
> soft-forks using a future nVersion bits deployment mechanism.
>
> For instance, suppose we start deployment of CLTV right now with
> nVersion=3D4 blocks. In three months we have 25% miner support, and start
> deploying CHECKSEQUENCEVERIFY with nVersion=3D5 blocks. For miners
> supporting only OP_CLTV, the nVersion=3D5 blocks still trigger OP_CLTV;
> miners creating nVersion=3D5 blocks are simply stating that they support
> both soft-forks. Equally, if in three months we finish a nVersion bits
> proposal, those miners will be advertising nVersion=3D(1 << 29) blocks,
> which also advertise OP_CLTV support.
>
>
> 8) BIP101 miners have not proved to be a problem for CLTV deployment
>
> While there was concern that BIP101's use of nVersion would cause
> issues with a IsSuperMajority() softfork, the % of blocks with BIP101
> nVersion's never reached more than 1%, and currently is hovering at
> around 0.1%
>
> As Gavin Andresen has stated that he is happy to add CLTV to BIP101, and
> thus Bitcoin XT, I believe we can expect those miners to safely support
> CLTV well before soft-fork enforcement happens. Secondly, the 95%
> enforcement threshold means we can tolerate a fairly high % of miners
> running pre-CLTV BIP101 implementations without fatal effects in the
> unlikely event that those miners don't upgrade.
>
>
> 9) Doing another IsSuperMajority() soft-fork doesn't "burn a bit"
>
> This is a common myth! All nVersion bits proposals involve permanently
> setting a high-order bit to 1, which results in nVersion >=3D all prior
> IsSuperMajority() soft-forks. In short, we can do a nearly unlimited
> number of IsSuperMajority() soft-forks without affecting future nVersion
> bits soft-forks at all.
>
>
> 10) Waiting for nVersion bits and CHECKSEQUENCEVERIFY will significantly
> delay deployment of CLTV
>
> It's been proposed multiple times that we wait until we can do a single
> soft-fork with CSV using the nVersion bits mechanism.
>
> nVersion bits doesn't even have an implementation yet, nor has solid
> consensus been reached on the exact semantics of how nVersion bits
> should work. The stateful nature of nVersion bits soft-forks requires a
> significant amount of new code compared to IsSuperMajority() soft-forks,
> which in turn will require a significant amount of testing. (again I'll
> point out I'm a co-author to all the nVersion bits proposals)
>
> CSV has an implementation, but there is still debate going on about what
> the exact semantics of it should be. Getting the semantics right is
> especially important as part of CSV includes changing the meaning of
> nSequence, restricting future uses of that field. There have been many
> proposals to use nSequence, e.g. for proof-of-stake blocksize voting,
> and it has the unique capability of being a field that is both unused,
> and signed by scriptSigs. We shouldn't take potentially restricting
> future uses of it lightly.
>
> CSV is also significantly more complex and invasive than CLTV in terms
> of code changes. A large % of the mining power is running forks
> of Bitcoin Core with custom changes - modifying these forks with new
> features is a labor intensive and slow process.
>
> If CLTV is ready now, why delay it - potentially for 6-12 months - for
> other proposals to catch up? Equally if they do catch up, great! As
> explained above an in-flight CLTV soft-fork won't delay future upgrades.
>
>
> 11) Even if CLTV is broken/obsoleted there is very little carrying cost
> to having it
>
> Suppose we decide in two years that CLTV was botched and we need to fix
> it. What's the "carrying cost" of having implemented CLTV in the first
> place?
>
> We'll have used up one of our ten soft-forkable NOPs, but if we ever
> "run out" it's easy to use extension NOPs(3). Similarly, future script
> improvements like OP_MAST - or even a hard-fork - can easily expand the
> range of NOPs to the point where this is a non-issue.
>
> If you don't use OP_CLTV in your scripts there is zero effect on your
> transactions; we're not limiting future improvements to Bitcoin in any
> way other than using up a NOP by implementing CLTV.
>
>
> References
> ----------
>
> 1) https://github.com/petertodd/checklocktimeverify-demos
> 2) https://github.com/mruddy/bip65-demos
> 3) https://github.com/bitcoin/bitcoin/pull/5496#issuecomment-101293403
> 4) https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000006a257845da185433cbde54a74be889b1c046a267dcf4ab2
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a113f7e7cb8e1e90520c06bd8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Agree with all CLTV and nVersionBits points. We should dep=
loy a lock-time soft-fork ASAP, using the tried and true IsSuperMajoirty te=
st.<br><br>However your information regarding BIPs 68 (sequence numbers), 1=
12 (checksequenceverify) and 113 (median time past) is outdated. Debate reg=
arding semantics has been settled, and there are working implementations re=
ady for merge on github. See pull requests #6312, #6564, and #6566. I don=
=E2=80=99t know what the hold up has been regarding further reviews and mer=
ging, but it is ready.<br><br>If you believe there are reasons #6312, #6564=
, or #6566 should not be merged, please speak up. Otherwise it appears ther=
e is consensus on these changes. They are related, and there is no reason n=
ot to include them in the soft-fork, delaying applications using these feat=
ures by 6-12 months.<br><br><div class=3D"gmail_extra"><div class=3D"gmail_=
quote">On Sun, Sep 27, 2015 at 11:50 AM, Peter Todd via bitcoin-dev <span d=
ir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" tar=
get=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">Summary<br>
-------<br>
<br>
It's time to deploy BIP65 CHECKLOCKTIMEVERIFY.<br>
<br>
I've backported the CLTV op-code and a IsSuperMajority() soft-fork to<b=
r>
the v0.10 and v0.11 branches, pull-reqs #6706 and #6707 respectively. A<br>
pull-req for git HEAD for the soft-fork deployment has been open since<br>
June 28th, #6351 - the opcode implementation itself was merged two<br>
months ago.<br>
<br>
We should release a v0.10.3 and v0.11.1 with CLTV and get the ball<br>
rolling on miner adoption. We have consensus that we need CLTV, we have<br>
a well tested implementation, and we have a well-tested deployment<br>
mechanism. We also don't need to wait for other soft-fork proposals to<=
br>
catch up - starting the CLTV deployment process isn't going to delay<br=
>
future soft-forks, or for that matter, hard-forks.<br>
<br>
I think it's possible to safely get CLTV live on mainnet before the end=
<br>
of the year. It's time we get this over with and done.<br>
<br>
<br>
Detailed Rational<br>
-----------------<br>
<br>
1) There is a clear need for CLTV<br>
<br>
Escrow and payment channels both benefit greatly from CLTV. In<br>
particular, payment channel implementations are made significantly<br>
simpler with CLTV, as well as more secure by removing the malleability<br>
vulnerability.<br>
<br>
Why are payment channels important? There's a lot of BTC out there<br>
vulnerable to theft that doesn't have to be. For example, just the othe=
r<br>
day I was talking with Nick Sullivan about ChangeTip's vulnerability to=
<br>
theft, as well as regulatory uncertainty about whether or not they're a=
<br>
custodian of their users' funds. With payment channels ChangeTip would<=
br>
only be able to spend as much of a deposit as a user had spent, keeping<br>
the rest safe from theft. Similarly, in the other direction - ChangeTip<br>
to their users - in many cases it is feasible to also use payment<br>
channels to immediately give users control of their funds as they<br>
receive them, again protecting users and helping make the case that<br>
they're not a custodian. In the future I'm sure we'll see fancy=
<br>
bi-directional payment channels serving this role, but lets not let<br>
perfect be the enemy of good.<br>
<br>
<br>
2) We have consensus on the semantics of the CLTV opcode<br>
<br>
Pull-req #6124 - the implementation of the opcode itself - was merged<br>
nearly three months ago after significant peer review and discussion.<br>
Part of that review process included myself(1) and mruddy(2) writing<br>
actual demos of CLTV. The chance of the CLTV semantics changing now is<br>
near-zero.<br>
<br>
<br>
3) We have consensus that Bitcoin should adopt CLTV<br>
<br>
The broad peer review and discussion that got #6124 merged is a clear<br>
sign that we expect CLTV to be eventually adopted. The question isn't i=
f<br>
CLTV should be added to the Bitcoin protocol, but rather when.<br>
<br>
<br>
4) The CLTV opcode and IsSuperMajority() deployment code has been<br>
=C2=A0 =C2=A0thoroughly tested and reviewed<br>
<br>
The opcode implementation is very simple, yet got significant review,<br>
and it has solid test coverage by a suite of tx-(in)valid.json tests.<br>
The tests themselves have been reviewed by others, resulting in Esteban<br>
Ordano's pull-req #6368 by Esteban Ordano which added a few more cases.=
<br>
<br>
As for the deployment code, both the actual IsSuperMajority() deployment<br=
>
code and associated unit-tests tests were copied nearly line-by-line<br>
from the succesful BIP66. I did this deliberately to make all the peer<br>
review and testing of the deployment mechanism used in BIP66 be equally<br>
valid for CLTV.<br>
<br>
<br>
5) We can safely deploy CLTV with IsSuperMajority()<br>
<br>
We've done two soft-forks so far with the IsSuperMajority() mechanism,<=
br>
BIP34 and BIP66. In both cases the IsSuperMajority() mechanism itself<br>
worked flawlessly. As is well-known BIP66 in combination with a large %<br>
of the hashing power running non-validating "SPV" mining operatio=
ns did<br>
lead to a temporary fork, however the root cause of this issue is<br>
unavoidable and not unique to IsSuperMajority() soft-forks.<br>
<br>
Pragmatically speaking, now that miners are well aware of the issue it<br>
will be easy for them to avoid a repeat of that fork by simply adding<br>
IsSuperMajority() rules to their "SPV" mining code. Equally turni=
ng off<br>
SPV mining (temporarily) is perfectly feasable.<br>
<br>
<br>
6) We have the necessary consensus to deploy CLTV via IsSuperMajority()<br>
<br>
The various "nVersion bits" proposals - which I am a co-author of=
- have<br>
the primary advantage of being able to cleanly deal with the case where<br>
a soft-fork fails to get adopted. However, we do have broad consensus,<br>
including across all sides of the blocksize debate, that CLTV should be<br>
adopted. The risk of CLTV failing to get miner adoption, and thus<br>
blocking other soft-forks, is very low.<br>
<br>
<br>
7) Using IsSuperMajority() to deploy CLTV doesn't limit or delay other =
upgrades<br>
<br>
It _is_ possible for multiple IsSuperMajority() soft-forks to coexist,<br>
in the sense that if one soft-fork is "in flight" that doesn'=
t prevent<br>
another soft-fork from also being deployed simultaneously.<br>
<br>
In particular, if we deploy CLTV via IsSuperMajority() that does _not_<br>
impact the adoption schedule for other future soft-forks, including<br>
soft-forks using a future nVersion bits deployment mechanism.<br>
<br>
For instance, suppose we start deployment of CLTV right now with<br>
nVersion=3D4 blocks. In three months we have 25% miner support, and start<b=
r>
deploying CHECKSEQUENCEVERIFY with nVersion=3D5 blocks. For miners<br>
supporting only OP_CLTV, the nVersion=3D5 blocks still trigger OP_CLTV;<br>
miners creating nVersion=3D5 blocks are simply stating that they support<br=
>
both soft-forks. Equally, if in three months we finish a nVersion bits<br>
proposal, those miners will be advertising nVersion=3D(1 << 29) block=
s,<br>
which also advertise OP_CLTV support.<br>
<br>
<br>
8) BIP101 miners have not proved to be a problem for CLTV deployment<br>
<br>
While there was concern that BIP101's use of nVersion would cause<br>
issues with a IsSuperMajority() softfork, the % of blocks with BIP101<br>
nVersion's never reached more than 1%, and currently is hovering at<br>
around 0.1%<br>
<br>
As Gavin Andresen has stated that he is happy to add CLTV to BIP101, and<br=
>
thus Bitcoin XT, I believe we can expect those miners to safely support<br>
CLTV well before soft-fork enforcement happens. Secondly, the 95%<br>
enforcement threshold means we can tolerate a fairly high % of miners<br>
running pre-CLTV BIP101 implementations without fatal effects in the<br>
unlikely event that those miners don't upgrade.<br>
<br>
<br>
9) Doing another IsSuperMajority() soft-fork doesn't "burn a bit&q=
uot;<br>
<br>
This is a common myth! All nVersion bits proposals involve permanently<br>
setting a high-order bit to 1, which results in nVersion >=3D all prior<=
br>
IsSuperMajority() soft-forks. In short, we can do a nearly unlimited<br>
number of IsSuperMajority() soft-forks without affecting future nVersion<br=
>
bits soft-forks at all.<br>
<br>
<br>
10) Waiting for nVersion bits and CHECKSEQUENCEVERIFY will significantly<br=
>
=C2=A0 =C2=A0 delay deployment of CLTV<br>
<br>
It's been proposed multiple times that we wait until we can do a single=
<br>
soft-fork with CSV using the nVersion bits mechanism.<br>
<br>
nVersion bits doesn't even have an implementation yet, nor has solid<br=
>
consensus been reached on the exact semantics of how nVersion bits<br>
should work. The stateful nature of nVersion bits soft-forks requires a<br>
significant amount of new code compared to IsSuperMajority() soft-forks,<br=
>
which in turn will require a significant amount of testing. (again I'll=
<br>
point out I'm a co-author to all the nVersion bits proposals)<br>
<br>
CSV has an implementation, but there is still debate going on about what<br=
>
the exact semantics of it should be. Getting the semantics right is<br>
especially important as part of CSV includes changing the meaning of<br>
nSequence, restricting future uses of that field. There have been many<br>
proposals to use nSequence, e.g. for proof-of-stake blocksize voting,<br>
and it has the unique capability of being a field that is both unused,<br>
and signed by scriptSigs. We shouldn't take potentially restricting<br>
future uses of it lightly.<br>
<br>
CSV is also significantly more complex and invasive than CLTV in terms<br>
of code changes. A large % of the mining power is running forks<br>
of Bitcoin Core with custom changes - modifying these forks with new<br>
features is a labor intensive and slow process.<br>
<br>
If CLTV is ready now, why delay it - potentially for 6-12 months - for<br>
other proposals to catch up? Equally if they do catch up, great! As<br>
explained above an in-flight CLTV soft-fork won't delay future upgrades=
.<br>
<br>
<br>
11) Even if CLTV is broken/obsoleted there is very little carrying cost<br>
=C2=A0 =C2=A0 to having it<br>
<br>
Suppose we decide in two years that CLTV was botched and we need to fix<br>
it. What's the "carrying cost" of having implemented CLTV in =
the first<br>
place?<br>
<br>
We'll have used up one of our ten soft-forkable NOPs, but if we ever<br=
>
"run out" it's easy to use extension NOPs(3). Similarly, futu=
re script<br>
improvements like OP_MAST - or even a hard-fork - can easily expand the<br>
range of NOPs to the point where this is a non-issue.<br>
<br>
If you don't use OP_CLTV in your scripts there is zero effect on your<b=
r>
transactions; we're not limiting future improvements to Bitcoin in any<=
br>
way other than using up a NOP by implementing CLTV.<br>
<br>
<br>
References<br>
----------<br>
<br>
1) <a href=3D"https://github.com/petertodd/checklocktimeverify-demos" rel=
=3D"noreferrer" target=3D"_blank">https://github.com/petertodd/checklocktim=
everify-demos</a><br>
2) <a href=3D"https://github.com/mruddy/bip65-demos" rel=3D"noreferrer" tar=
get=3D"_blank">https://github.com/mruddy/bip65-demos</a><br>
3) <a href=3D"https://github.com/bitcoin/bitcoin/pull/5496#issuecomment-101=
293403" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/bit=
coin/pull/5496#issuecomment-101293403</a><br>
4) <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0112.mediawik=
i" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/bips/blo=
b/master/bip-0112.mediawiki</a><br>
<span class=3D""><font color=3D"#888888"><br>
--<br>
'peter'[:-1]@<a href=3D"http://petertodd.org" rel=3D"noreferrer" ta=
rget=3D"_blank">petertodd.org</a><br>
000000000000000006a257845da185433cbde54a74be889b1c046a267dcf4ab2<br>
</font></span><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></div>
--001a113f7e7cb8e1e90520c06bd8--
|