<p>Setting the <code>nLockTime</code> field of a transaction restricts confirmation of the <strong>current transaction</strong> until a certain block height.<br />
Using a <code>CLTV</code> op in the locking script of an output of the current transaction will restrict the confirmation of the <strong>next transaction</strong> (i.e. the one that spends this output), by forcing the next transaction's <code>nLockTime</code> to be greater than or equal to the value passed to the <code>CLTV</code> opcode.</p>
<p>Let's say you have two transactions in the two scenarios. The block height at the time of writing is <code>637028</code>.</p>
<ul>
<li><code>A</code> is a (one input, one output) transaction on which the <code>nLockTime</code> field is set to <code>637100</code>. <code>B</code> is a (one input, one output) transaction which spends <code>A</code>.</li>
<li><code>C</code> is a (one input, one output) transaction on which the <code>nLockTime</code> field is set to <code>0</code>, but which specifies <code>637100 CLTV DROP</code> as part of the &quot;locking&quot; script of its single output. <code>D</code> is a (one input, one output) transaction which spends <code>C</code>.</li>
</ul>
<pre><code>           A                            B
 _____________________        ______________________
|   nLockTime=637100  |-----&gt;|     nLockTime=0      |
|_____________________|      |______________________|


           C                            D
 _____________________        ______________________
|   CLTV=637100       |-----&gt;|     nLockTime=637100 |
|____________\________|      |_________________/|\__|
              \                                 |
               \________this forces_____________|

</code></pre>
<p>Both packages cannot be mined as a whole at height <code>637028</code>, however in the second scenario, <code>C</code> <em>can</em> be mined: this indirection is the point of the <code>CLTV</code> opcode. More about the details and usecases <a href="https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki" rel="nofollow noreferrer">in bip-0065</a>.</p>

CC BY-SA 4.0
2020-06-30T12:13:50.783Z
2023-10-05T11:09:59.413Z
2023-10-05T11:09:59.413Z
Antoine Poinsot
<p>The nLockTime field and the CLTV opcode both specify absolute time-locks. The difference is that nLockTime applies to an entire transaction whereas CLTV applies to the spending of a single transaction output. A transaction with an enabled nLockTime cannot be mined until the block height or time specified in the nLockTime has passed. A transaction output encumbered with a CLTV opcode cannot be spent unless the spending transaction has an nLockTime that is greater than or equal to the CLTV parameter.</p>
<p>In your example, you are correct that T cannot be mined until time 400. However, the CLTV value applies to a single transaction output that is being spent by T. The two values could be set by different people. If the CLTV value was 200, the transaction output <em>could</em> have been spent by a transaction with an nLockTime of 200. Similarly, if the CLTV value was 300, the transaction output <em>could</em> have been spent by a transaction with an nLockTime of 300, but not 200. Of course, a transaction with an nLockTime of 400 could spend the transaction output in either case.</p>

CC BY-SA 4.0
2020-06-30T11:11:04.523Z
2020-06-30T11:11:04.523Z
Martin Harrigan
<p>What is the difference between nLockTime and CLTV? <a href="https://en.bitcoin.it/wiki/Timelock" rel="noreferrer">Bitcoin Wiki</a> says:</p>

<blockquote>
  <p>When the CLTV opcode is called, it will cause the script to fail unless the nLockTime on the transaction is equal to or greater than the time parameter provided to the CLTV opcode. Since a transaction may only be included in a valid block if its nLockTime is in the past, this ensures the CLTV-based timelock has expired before the transaction may be included in a valid block.</p>
</blockquote>

<p>According to the above description, it's unclear to me how the parameter to CLTV is used. For example, for a transaction T with nLockTime=400, CLTV=300, the above description basically says since T remains invalid until 400 (due to nLockTime), CLTV=300 must have been satisfied by height 400. True but what's the point? What would be different if T has CTLV=200?</p>

<locktime><checklocktimeverify>
CLTV vs nLockTime
qweruiop
# CLTV vs nLockTime

(Asked by: username_0 on 2018-03-07)

What is the difference between nLockTime and CLTV? [Bitcoin Wiki](https://en.bitcoin.it/wiki/Timelock) says:

> When the CLTV opcode is called, it will cause the script to fail unless the nLockTime on the transaction is equal to or greater than the time parameter provided to the CLTV opcode. Since a transaction may only be included in a valid block if its nLockTime is in the past, this ensures the CLTV-based timelock has expired before the transaction may be included in a valid block.

According to the above description, it's unclear to me how the parameter to CLTV is used. For example, for a transaction T with nLockTime=400, CLTV=300, the above description basically says since T remains invalid until 400 (due to nLockTime), CLTV=300 must have been satisfied by height 400. True but what's the point? What would be different if T has CTLV=200?

**Tags:** locktime, checklocktimeverify


---

## 2 answers

### Answer by username_1 on 2020-06-30. Score: 8

Setting the `nLockTime` field of a transaction restricts confirmation of the **current transaction** until a certain block height.  
Using a `CLTV` op in the locking script of an output of the current transaction will restrict the confirmation of the **next transaction** (i.e. the one that spends this output), by forcing the next transaction's `nLockTime` to be greater than or equal to the value passed to the `CLTV` opcode.

Let's say you have two transactions in the two scenarios. The block height at the time of writing is `637028`.

* `A` is a (one input, one output) transaction on which the `nLockTime` field is set to `637100`. `B` is a (one input, one output) transaction which spends `A`.
* `C` is a (one input, one output) transaction on which the `nLockTime` field is set to `0`, but which specifies `637100 CLTV DROP` as part of the "locking" script of its single output. `D` is a (one input, one output) transaction which spends `C`.

```
           A                            B
 _____________________        ______________________
|   nLockTime=637100  |----->|     nLockTime=0      |
|_____________________|      |______________________|

           C                            D
 _____________________        ______________________
|   CLTV=637100       |----->|     nLockTime=637100 |
|____________\________|      |_________________/|\__|
              \                                 |
               \________this forces_____________|

```

Both packages cannot be mined as a whole at height `637028`, however in the second scenario, `C` *can* be mined: this indirection is the point of the `CLTV` opcode. More about the details and usecases [in bip-0065](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki).


---

### Answer by username_2 on 2020-06-30. Score: 0

The nLockTime field and the CLTV opcode both specify absolute time-locks. The difference is that nLockTime applies to an entire transaction whereas CLTV applies to the spending of a single transaction output. A transaction with an enabled nLockTime cannot be mined until the block height or time specified in the nLockTime has passed. A transaction output encumbered with a CLTV opcode cannot be spent unless the spending transaction has an nLockTime that is greater than or equal to the CLTV parameter.

In your example, you are correct that T cannot be mined until time 400. However, the CLTV value applies to a single transaction output that is being spent by T. The two values could be set by different people. If the CLTV value was 200, the transaction output *could* have been spent by a transaction with an nLockTime of 200. Similarly, if the CLTV value was 300, the transaction output *could* have been spent by a transaction with an nLockTime of 300, but not 200. Of course, a transaction with an nLockTime of 400 could spend the transaction output in either case.


---

