user74134: What is the difference between nLockTime and CLTV? Bitcoin Wiki 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?

user101498: 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 equal to the value passed to the CLTV opcode.
Let's say you have two transactions in the two scenarii. The block height at the time of writing is 637028.

A is a (one input, one output) transaction which 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 which 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 before 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.

74134: <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>
 101498: <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 equal to the value passed to the <code>CLTV</code> opcode.</p>
<p>Let's say you have two transactions in the two scenarii. 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 which <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 which <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 before 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>
