<p>Citing <a href="https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki" rel="noreferrer">BIP65</a>, which introduced <code>OP_CHECKLOCKTIMEVERIFY</code>:</p>
<blockquote>
<p>When executed, if any of the following conditions are true, the script interpreter will terminate with an error:</p>
<ul>
<li>the stack is empty; or</li>
<li>the top item on the stack is less than 0; or</li>
<li>the lock-time type (height vs. timestamp) of the top stack item and the nLockTime field are not the same; or</li>
<li>the top stack item is greater than the transaction's nLockTime field; or
the nSequence field of <strong>the</strong> txin is 0xffffffff;</li>
</ul>
</blockquote>
<p>(emphasis mine)</p>
<p>So <code>OP_CHECKLOCKTIMEVERIFY</code> requires the <code>nSequence</code> value of the spending input itself to not be 0xffffffff. While it technically suffices that at least one input has a non-0xffffffff <code>nSequence</code> for the spending transaction to have a relevant <code>nLockTime</code>, the choice was made in BIP65 to require that the input itself has such an <code>nSequence</code>. According to the implementation's source code, this was done to minimize the amount of data needed to prove an input is correct.</p>

CC BY-SA 4.0
2023-10-29T19:17:08.257Z
2023-10-29T19:32:44.627Z
2023-10-29T19:32:44.627Z
Pieter Wuille
<p>Looking at the <a href="https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki" rel="nofollow noreferrer">BIP65</a>, it says that the CLTV will fail if the nSequence field of the txin is 0xffffffff. It seems logical to me since if the nSequence of all inputs are set to 0xffffffff, the value of nLocktime and absolute time are not taken into consideration. However, does the nSequence of the input that consumes output with CLTV must be != 0xffffffff, or the nSequence of any input inside the transaction can be != 0xffffffff and the input that consumes output with CLTV can stay with nSequence set to <code>0xffffffff</code> and that CLTV still pass? <strong>I am asking because in both cases the locktime and absolute time lock will be taken into consideration, that is, the locktime will be activated.</strong> Thanks.</p>

<sequence><checklocktimeverify>
Does the nSequence of the input that consumes the CLTV output have to be different from 0xffffffff?
LeaBit
# Does the nSequence of the input that consumes the CLTV output have to be different from 0xffffffff?

(Asked by: username_0 on 2023-10-29)

Looking at the [BIP65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki), it says that the CLTV will fail if the nSequence field of the txin is 0xffffffff. It seems logical to me since if the nSequence of all inputs are set to 0xffffffff, the value of nLocktime and absolute time are not taken into consideration. However, does the nSequence of the input that consumes output with CLTV must be != 0xffffffff, or the nSequence of any input inside the transaction can be != 0xffffffff and the input that consumes output with CLTV can stay with nSequence set to `0xffffffff` and that CLTV still pass? **I am asking because in both cases the locktime and absolute time lock will be taken into consideration, that is, the locktime will be activated.** Thanks.

**Tags:** sequence, checklocktimeverify


---

## 1 answers

### Answer by username_1 on 2023-10-29. Score: 5 | Accepted answer

Citing [BIP65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki), which introduced `OP_CHECKLOCKTIMEVERIFY`:

> When executed, if any of the following conditions are true, the script interpreter will terminate with an error:
>
> * the stack is empty; or
> * the top item on the stack is less than 0; or
> * the lock-time type (height vs. timestamp) of the top stack item and the nLockTime field are not the same; or
> * the top stack item is greater than the transaction's nLockTime field; or
>   the nSequence field of **the** txin is 0xffffffff;

(emphasis mine)

So `OP_CHECKLOCKTIMEVERIFY` requires the `nSequence` value of the spending input itself to not be 0xffffffff. While it technically suffices that at least one input has a non-0xffffffff `nSequence` for the spending transaction to have a relevant `nLockTime`, the choice was made in BIP65 to require that the input itself has such an `nSequence`. According to the implementation's source code, this was done to minimize the amount of data needed to prove an input is correct.


---

