summaryrefslogtreecommitdiff
path: root/af/07a6c3f7de6dd5a4c89806acc3dea57153e748
blob: 07c1f2178fc94ed2cbcc3001cc24fec147de1c0e (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
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
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 DCE6C1D81
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  6 Oct 2015 00:19:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com
	[209.85.213.169])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9F29A79
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  6 Oct 2015 00:19:26 +0000 (UTC)
Received: by igcpb10 with SMTP id pb10so75714239igc.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 05 Oct 2015 17:19:26 -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=TWP3LAsMkx2mo0mcv0cOVbgPN7ecIG5VLAoxKwUSZlE=;
	b=FUqC06Vt6W/PkIUBX5EWTbq5+GOngsnEaKaijq+HYY1SUPRqtkTFkT2txIyr+f5pnZ
	HgunSHUqtHmZfPBzFXpvHJJhfXFTu6Ce7UgqPdfnAC1ZNlOCSsQQJGwKKK94ENAPaWrM
	KSE4Yo/akRrOlbxt14+jfLAPATskWumWoYQeKNkPmW3HTchQWGT8U7ks2C4y94Se2Acv
	HGMJBJzk/6CzRuvtr6nN+nanmYD885eOL4xHepvaQ+FR1/GI4eD0RKg2NOM0zB24Wk58
	VC4Zy376qjjixKnR/tTCc821ZvVyWg9PqlI10BjobKnaV2xIGs5TbjTSQ51Ppet7DLJQ
	bM+Q==
X-Gm-Message-State: ALoCoQmijq/ufgivKxpskP6OHVbTv57zZkKxWnhUU6D/6sMPilQSpVPtYS6Cd11XLlN/sBfS3Uqe
X-Received: by 10.50.30.39 with SMTP id p7mr12682133igh.40.1444090766085; Mon,
	05 Oct 2015 17:19:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.135.104 with HTTP; Mon, 5 Oct 2015 17:19:06 -0700 (PDT)
X-Originating-IP: [173.228.107.141]
In-Reply-To: <CAPWm=eUiXAagzasLmKQWRT5EKnMxfeiv6J7M9mm+MhDzG_VwQg@mail.gmail.com>
References: <20151003143056.GA27942@muck> <20151004083525.GA18291@navy>
	<561115C0.3080601@sky-ip.org>
	<CAPWm=eUiXAagzasLmKQWRT5EKnMxfeiv6J7M9mm+MhDzG_VwQg@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Mon, 5 Oct 2015 17:19:06 -0700
Message-ID: <CAOG=w-uEwwDGA3_RF1Epp=xLG7rS4y2O7f9EOfAUa1hAiWkLGQ@mail.gmail.com>
To: Alex Morcos <morcos@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bdca5c02307360521649522
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 <bitcoin-dev@lists.linuxfoundation.org>,
	Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to
 motivate the change
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: Tue, 06 Oct 2015 00:19:29 -0000

--047d7bdca5c02307360521649522
Content-Type: text/plain; charset=UTF-8

Alex, decreasing granularity is a soft-fork, increasing is a hard-fork.
Therefore I've kept the highest possible precision (1 second, 1 block) with
the expectation that at some point in the future if we need more low-order
bits we can soft-fork them to other purposes, we can decrease granularity
at that time.

On Mon, Oct 5, 2015 at 3:03 PM, Alex Morcos via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Peter,
>
> Your concern about whether this is the best way to use the nSequence
> field; would that be addressed by providing more high order bits to signal
> different uses of the field?  At a certain point we're really not limiting
> the future at all and there is something to be said for not letting the
> perfect be the enemy of the good.  I think it would be nice to make forward
> progress on BIPS 68,112, and 113 and move towards getting them finalized
> and implemented.  (Although I do suspect they aren't quite ready to go out
> with CLTV)
>
> What is the reasoning for having single second resolution on the time
> based sequence number locks?  Might it not make some sense to reduce that
> resolution and leave more low order bits as well?
>
> Alex
>
> On Sun, Oct 4, 2015 at 8:04 AM, s7r via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> Hi aj,
>>
>> On 10/4/2015 11:35 AM, Anthony Towns via bitcoin-dev wrote:
>> > On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via
>> > bitcoin-dev wrote:
>> >> So we need to make the case for two main things: 1) We have
>> >> applications that need a relative (instead of absolute CLTV) 2)
>> >> Additionally to RCLTV, we need to implement this via nSequence
>> >
>> >> However I don't think we've done a good job showing why we need
>> >> to implement this feature via nSequence. BIP68 describes the new
>> >> nSequence semantics, and gives the rational for them as being a
>> >> "Consensus-enforced tx replacement" mechanism, with a
>> >> bidirectional payment channel as an example of this in action.
>> >> However, the bidirectional payment channel concept itself can be
>> >> easily implemented with CLTV alone.
>> >
>> > Do you mean "with RCLTV alone" here?
>> >
>> > RCLTV/OP_CSV is used in lightning commitment transactions to
>> > enforce a delay between publishing the commitment transaction, and
>> > spending the output -- that delay is needed so that the
>> > counterparty has time to prove the commitment was revoked and claim
>> > the outputs as a penalty.
>> >
>>
>> I partially understand - can you please provide a simple Alice and Bob
>> example here with the exact scenario? Thanks. Why is there a need to
>> 'delay between publishing the commitment transaction and spending the
>> output'? If the absolute CLTV script reached its maturity it means
>> something went wrong (e.g. counterparty cheated or got hit by a bus)
>> so what is with the delay time needed for proving that the commitment
>> was revoked? I assume an absolute CLTV script reaching its maturity
>> (nLockTime) is the proof itself that the commitment was revoked - but
>> maybe I'm missing something obvious, sorry if this is the case.
>>
>> > Using absolute CLTV instead would mean that once the effective
>> > delay a commitment transaction has decreases over time -- initially
>> > it will be longer than desirable, causing unwanted delays in
>> > claiming funds when no cheating is going on; but over time it will
>> > become too short, which means there is not enough time to prove
>> > cheating (and the channel has to be closed prematurely). You can
>> > trade those things off and pick something that works, but it's
>> > always going to be bad.
>> >
>> I agree, I see the logic here. Absolute CLTV is not necessary inferior
>> to RCLTV - there are use cases and use cases. For example, you can
>> avoid unnecessary waiting until the nLockTime expires if you use
>> absolute CLTV in combination with P2SH (2/2). Again, it always depends
>> on the use case - it might be a good solution, it might not be such a
>> good solution, but even absolute CLTV alone clearly fixes a lot of
>> things and takes smart contracts to the next level.
>>
>> >> There is a small drawback in that the initial transaction could
>> >> be delayed, reducing the overall time the channel exists, but the
>> >> protocol already assumes that transactions can be reliably
>> >> confirmed within a day - significantly less than the proposed 30
>> >> days duration of the channel.
>> >
>> > Compared to using a CLTV with 30 days duration, With RCLTV a
>> > channel could be available for years (ie 20x longer), but in the
>> > case of problems funds could be reclaimed within hours or days (ie
>> > 30x faster).
>> >
>> Indeed. I for one _need_ CLTV / RCLTV in my day to day use cases, it
>> would be neat to have both, but if I can only have (for the time
>> being) absolute CLTV so be it - it's still a lot better.
>>
>> > But that's all about RCLTV vs CLTV, not about RCLTV vs
>> > nSequence/OP_CSV. ie, it needs BIP 112 (OP_CSV) but not necessarily
>> > BIP 68 (nSequence relative locktime), if they could be
>> > disentangled.
>> >
>> > You could do all that with "<n> OP_CHECK_HEIGHT_DELTA_VERIFY" that
>> > ignores nSequence, and directly compares the height of the current
>> > block versus the input tx's block (or the diff of their
>> > timestamps?) though, I think?
>> >
>> > I think the disadvantage is that (a) you have to look into the
>> > input transaction's block height when processing the script; and
>> > (b) you don't have an easy lookup to check whether the transaction
>> > can be included in the next block.
>> >
>> > You could maybe avoid (b) by using locktime though. Have "<n>
>> > OP_CHECK_RELATIVE_LOCKTIME_VERIFY" compare the transactions
>> > locktime against the input's block height or time; if the locktime
>> > is 0 or too low, the transaction is invalid. (So if nLockTime is in
>> > blockheight, you can only spend inputs with blockheight based
>> > OP_CRLTV tests; and if it's in blocktime, you can only spend inputs
>> > with blocktime based OP_CRLTV. "n" does need to encode whether it's
>> > time/block height though).
>> >
>> > That way, when you see a txn:
>> >
>> > - run the script. if you see <n> RCLTV, then + if the tx's locktime
>> > isn't set, it's invalid; drop it + if the input txn is unconfirmed,
>> > it's invalid; try again later + workout "locktime - n" if that's >=
>> > the input tx's block height/time, it's good; keep it in mempool,
>> > forward it, etc
>> >
>> > - if you're mining, include the tx when locktime hits, just like
>> > you would any other valid tx with a locktime
>> >
>> > I think the use cases for BIP68 (nSequence) are of the form:
>> >
>> > 1) published input; here's a signed tx that spends it to you,
>> > usable after a delay. might as well just use absolute locktime
>> > here, though.
>> >
>> > 2) here's an unpublished input, you can build your own transaction
>> > to spend it, just not immediately after it's published. BIP112 is
>> > required, and OP_RCLTV as defined above works fine, just include
>> > it in the published input's script.
>> >
>> > 3) here's an unpublished input, and a signed transaction spending
>> > it, that you can use to spend it after a delay. BIP68 is enough;
>> > but OP_RCLTV in the second transaction works here. however without
>> > normalised tx ids, the input could be malleated before
>> > publication, so maybe this use case isn't actually important
>> > anyway.
>> >
>> > So I think OP_CRLTV alone works fine for them too...
>> >
>> > (Does that make sense, or am I missing something obvious?)
>> >
>> > Cheers, aj
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.22 (MingW32)
>>
>> iQEcBAEBCAAGBQJWERXAAAoJEIN/pSyBJlsRypMH/2Q+jVRf4hWtPr9cs/06pXM9
>> mKHd2OPDEJO8HjSe+cIMCxOz76EZxXglUEkK4YV/huP0Tp0bcMp6EJxsZVD9L78k
>> dugyh2747ddL6aqRmt0ducTEfIC/Q4BxPA2HRQZkvyyIUQv2Tyo780bC0y8BwUpb
>> j/BQjFZwk4QgqkTlf5lbCgn85alOKHki2El04iALHc27pUiDWKQPPeNOy6po6mmD
>> /csvh4XOTQwCVy384ljuFBp0+QN7Z/zx4E8i6GqV2BmfNcveTG6Fc5KrHr2Ud4Th
>> RD8k6n9mLaPs6ufhVkgUiUqPzQsJ+ns+mm7OEUdd645Kxqxg3Tu1u32DgdpRcHk=
>> =U0N6
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> 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
>
>

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

<div dir=3D"ltr">Alex, decreasing granularity is a soft-fork, increasing is=
 a hard-fork. Therefore I&#39;ve kept the highest possible precision (1 sec=
ond, 1 block) with the expectation that at some point in the future if we n=
eed more low-order bits we can soft-fork them to other purposes, we can dec=
rease granularity at that time.<br></div><div class=3D"gmail_extra"><br><di=
v class=3D"gmail_quote">On Mon, Oct 5, 2015 at 3:03 PM, Alex Morcos via bit=
coin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfou=
ndation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Peter,<d=
iv><br></div><div>Your concern about whether this is the best way to use th=
e nSequence field; would that be addressed by providing more high order bit=
s to signal different uses of the field?=C2=A0 At a certain point we&#39;re=
 really not limiting the future at all and there is something to be said fo=
r not letting the perfect be the enemy of the good.=C2=A0 I think it would =
be nice to make forward progress on BIPS 68,112, and 113 and move towards g=
etting them finalized and implemented. =C2=A0(Although I do suspect they ar=
en&#39;t quite ready to go out with CLTV)</div><div><br></div><div>What is =
the reasoning for having single second resolution on the time based sequenc=
e number locks?=C2=A0 Might it not make some sense to reduce that resolutio=
n and leave more low order bits as well?</div><div><br></div><div>Alex</div=
></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><=
br><div class=3D"gmail_quote">On Sun, Oct 4, 2015 at 8:04 AM, s7r via bitco=
in-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;<=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSA=
GE-----<br>
Hash: SHA256<br>
<br>
Hi aj,<br>
<span><br>
On 10/4/2015 11:35 AM, Anthony Towns via bitcoin-dev wrote:<br>
&gt; On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via<br>
&gt; bitcoin-dev wrote:<br>
&gt;&gt; So we need to make the case for two main things: 1) We have<br>
&gt;&gt; applications that need a relative (instead of absolute CLTV) 2)<br=
>
&gt;&gt; Additionally to RCLTV, we need to implement this via nSequence<br>
&gt;<br>
&gt;&gt; However I don&#39;t think we&#39;ve done a good job showing why we=
 need<br>
&gt;&gt; to implement this feature via nSequence. BIP68 describes the new<b=
r>
&gt;&gt; nSequence semantics, and gives the rational for them as being a<br=
>
&gt;&gt; &quot;Consensus-enforced tx replacement&quot; mechanism, with a<br=
>
&gt;&gt; bidirectional payment channel as an example of this in action.<br>
&gt;&gt; However, the bidirectional payment channel concept itself can be<b=
r>
&gt;&gt; easily implemented with CLTV alone.<br>
&gt;<br>
&gt; Do you mean &quot;with RCLTV alone&quot; here?<br>
&gt;<br>
&gt; RCLTV/OP_CSV is used in lightning commitment transactions to<br>
&gt; enforce a delay between publishing the commitment transaction, and<br>
&gt; spending the output -- that delay is needed so that the<br>
&gt; counterparty has time to prove the commitment was revoked and claim<br=
>
&gt; the outputs as a penalty.<br>
&gt;<br>
<br>
</span>I partially understand - can you please provide a simple Alice and B=
ob<br>
example here with the exact scenario? Thanks. Why is there a need to<br>
&#39;delay between publishing the commitment transaction and spending the<b=
r>
output&#39;? If the absolute CLTV script reached its maturity it means<br>
something went wrong (e.g. counterparty cheated or got hit by a bus)<br>
so what is with the delay time needed for proving that the commitment<br>
was revoked? I assume an absolute CLTV script reaching its maturity<br>
(nLockTime) is the proof itself that the commitment was revoked - but<br>
maybe I&#39;m missing something obvious, sorry if this is the case.<br>
<span><br>
&gt; Using absolute CLTV instead would mean that once the effective<br>
&gt; delay a commitment transaction has decreases over time -- initially<br=
>
&gt; it will be longer than desirable, causing unwanted delays in<br>
&gt; claiming funds when no cheating is going on; but over time it will<br>
&gt; become too short, which means there is not enough time to prove<br>
&gt; cheating (and the channel has to be closed prematurely). You can<br>
&gt; trade those things off and pick something that works, but it&#39;s<br>
&gt; always going to be bad.<br>
&gt;<br>
</span>I agree, I see the logic here. Absolute CLTV is not necessary inferi=
or<br>
to RCLTV - there are use cases and use cases. For example, you can<br>
avoid unnecessary waiting until the nLockTime expires if you use<br>
absolute CLTV in combination with P2SH (2/2). Again, it always depends<br>
on the use case - it might be a good solution, it might not be such a<br>
good solution, but even absolute CLTV alone clearly fixes a lot of<br>
things and takes smart contracts to the next level.<br>
<span><br>
&gt;&gt; There is a small drawback in that the initial transaction could<br=
>
&gt;&gt; be delayed, reducing the overall time the channel exists, but the<=
br>
&gt;&gt; protocol already assumes that transactions can be reliably<br>
&gt;&gt; confirmed within a day - significantly less than the proposed 30<b=
r>
&gt;&gt; days duration of the channel.<br>
&gt;<br>
&gt; Compared to using a CLTV with 30 days duration, With RCLTV a<br>
&gt; channel could be available for years (ie 20x longer), but in the<br>
&gt; case of problems funds could be reclaimed within hours or days (ie<br>
&gt; 30x faster).<br>
&gt;<br>
</span>Indeed. I for one _need_ CLTV / RCLTV in my day to day use cases, it=
<br>
would be neat to have both, but if I can only have (for the time<br>
being) absolute CLTV so be it - it&#39;s still a lot better.<br>
<div><div><br>
&gt; But that&#39;s all about RCLTV vs CLTV, not about RCLTV vs<br>
&gt; nSequence/OP_CSV. ie, it needs BIP 112 (OP_CSV) but not necessarily<br=
>
&gt; BIP 68 (nSequence relative locktime), if they could be<br>
&gt; disentangled.<br>
&gt;<br>
&gt; You could do all that with &quot;&lt;n&gt; OP_CHECK_HEIGHT_DELTA_VERIF=
Y&quot; that<br>
&gt; ignores nSequence, and directly compares the height of the current<br>
&gt; block versus the input tx&#39;s block (or the diff of their<br>
&gt; timestamps?) though, I think?<br>
&gt;<br>
&gt; I think the disadvantage is that (a) you have to look into the<br>
&gt; input transaction&#39;s block height when processing the script; and<b=
r>
&gt; (b) you don&#39;t have an easy lookup to check whether the transaction=
<br>
&gt; can be included in the next block.<br>
&gt;<br>
&gt; You could maybe avoid (b) by using locktime though. Have &quot;&lt;n&g=
t;<br>
&gt; OP_CHECK_RELATIVE_LOCKTIME_VERIFY&quot; compare the transactions<br>
&gt; locktime against the input&#39;s block height or time; if the locktime=
<br>
&gt; is 0 or too low, the transaction is invalid. (So if nLockTime is in<br=
>
&gt; blockheight, you can only spend inputs with blockheight based<br>
&gt; OP_CRLTV tests; and if it&#39;s in blocktime, you can only spend input=
s<br>
&gt; with blocktime based OP_CRLTV. &quot;n&quot; does need to encode wheth=
er it&#39;s<br>
&gt; time/block height though).<br>
&gt;<br>
&gt; That way, when you see a txn:<br>
&gt;<br>
&gt; - run the script. if you see &lt;n&gt; RCLTV, then + if the tx&#39;s l=
ocktime<br>
&gt; isn&#39;t set, it&#39;s invalid; drop it + if the input txn is unconfi=
rmed,<br>
&gt; it&#39;s invalid; try again later + workout &quot;locktime - n&quot; i=
f that&#39;s &gt;=3D<br>
&gt; the input tx&#39;s block height/time, it&#39;s good; keep it in mempoo=
l,<br>
&gt; forward it, etc<br>
&gt;<br>
&gt; - if you&#39;re mining, include the tx when locktime hits, just like<b=
r>
&gt; you would any other valid tx with a locktime<br>
&gt;<br>
&gt; I think the use cases for BIP68 (nSequence) are of the form:<br>
&gt;<br>
&gt; 1) published input; here&#39;s a signed tx that spends it to you,<br>
&gt; usable after a delay. might as well just use absolute locktime<br>
&gt; here, though.<br>
&gt;<br>
&gt; 2) here&#39;s an unpublished input, you can build your own transaction=
<br>
&gt; to spend it, just not immediately after it&#39;s published. BIP112 is<=
br>
&gt; required, and OP_RCLTV as defined above works fine, just include<br>
&gt; it in the published input&#39;s script.<br>
&gt;<br>
&gt; 3) here&#39;s an unpublished input, and a signed transaction spending<=
br>
&gt; it, that you can use to spend it after a delay. BIP68 is enough;<br>
&gt; but OP_RCLTV in the second transaction works here. however without<br>
&gt; normalised tx ids, the input could be malleated before<br>
&gt; publication, so maybe this use case isn&#39;t actually important<br>
&gt; anyway.<br>
&gt;<br>
&gt; So I think OP_CRLTV alone works fine for them too...<br>
&gt;<br>
&gt; (Does that make sense, or am I missing something obvious?)<br>
&gt;<br>
&gt; Cheers, aj<br>
</div></div>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2.0.22 (MingW32)<br>
<br>
iQEcBAEBCAAGBQJWERXAAAoJEIN/pSyBJlsRypMH/2Q+jVRf4hWtPr9cs/06pXM9<br>
mKHd2OPDEJO8HjSe+cIMCxOz76EZxXglUEkK4YV/huP0Tp0bcMp6EJxsZVD9L78k<br>
dugyh2747ddL6aqRmt0ducTEfIC/Q4BxPA2HRQZkvyyIUQv2Tyo780bC0y8BwUpb<br>
j/BQjFZwk4QgqkTlf5lbCgn85alOKHki2El04iALHc27pUiDWKQPPeNOy6po6mmD<br>
/csvh4XOTQwCVy384ljuFBp0+QN7Z/zx4E8i6GqV2BmfNcveTG6Fc5KrHr2Ud4Th<br>
RD8k6n9mLaPs6ufhVkgUiUqPzQsJ+ns+mm7OEUdd645Kxqxg3Tu1u32DgdpRcHk=3D<br>
=3DU0N6<br>
-----END PGP SIGNATURE-----<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>
</div></div></blockquote></div><br></div>
</div></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>

--047d7bdca5c02307360521649522--