<p><code>nLockTime</code> affects transaction validity only, if you make a transaction with an <code>nLockTime</code> in the future (by block height or unix time) it is invalid until that time has been passed. This means that if you sign a locked transaction, you can also just as easily sign a different transaction spending the same outputs that is spendable today. </p>

<ul>
<li><p>This is useful if you wanted to make a contingency transaction and give it to a third party which spends the output to a charity if you aren't around to make use of it in a years time. If you are around you can spend it in an alternate way, if you aren't a third party can broadcast the locked transaction to the network once it has become valid. </p></li>
<li><p>The limitation is in that you can't prove that funds are actually locked in this state, there's no way of knowing that the person won't just spend around an <code>nLockTime</code> transaction in a different way and bypass the restriction on when they could spend the funds. Setups are possible where a user sends an output to a new key, makes a locked transaction to themselves at another address, then destroys the private key, but this is incredibly flimsy and has no real assurances that the key wasn't retained secretly. </p></li>
</ul>

<p><code>CHECKLOCKTIMEVERIFY</code> is a new proposed opcode that allows you to use the current real time in a transaction script, allowing some more interesting and provable use cases that involve actually locking money rather than a particular transaction. This is closer behavior to how people normally think <code>nLockTime</code> should operate when they first hear about it. </p>

<ul>
<li><p>With CLTV, scripts that have different preconditions for spending based on the time are possible. Rather than limiting to a single presigned <code>nLockTime</code> transaction, a person could have every transaction in their wallet spendable by a specific charity key if 2 years pass without them being spent, or a 2-of-3 multisignature could have a contingency backdoor where an additional party can be included if the funds have not been used for an appreciable amount of time.</p></li>
<li><p>CLTV also allows for payment channels to be used even with transaction malleability. A mutated transaction can break <code>nLockTime</code> refund transactions at any point, which makes them quite risky at present. With CLTV the payment channel transactions can just timeout and be refunded to the creator without the need for any further interaction. </p></li>
</ul>

<p>BIP65 is potentially dangerous to end users as there are pretty much no take backs (if you lock your money for 5 years, there's no back doors or workarounds that will get your money back before then), but that said, that's a user interface problem rather than a fundamental security one. There's little contention about soft forking this change into the Bitcoin codebase in the future. </p>

CC BY-SA 3.0
2015-07-08T03:29:48.443Z
So, if I'm understanding correctly, CTLV writes un-spendable UTXOs into the Blockchain (until the time limit is valid). What about ntimelock? These Txs wouldn't be written in as UTXOs, right?
Wizard Of Ozzie
CC BY-SA 3.0
2015-09-06T21:06:56.633Z
Possibly, it depends how you use the CLTV opcode, it's just a switch you can use to decide spend-ability on. A nLockTime transaction is invalid before it is unlocked, a block that includes a transaction before its nLockTime is invalid as a consensus rule. They also can not be broadcast through the P2P network.
Claris
CC BY-SA 3.0
2015-07-07T12:05:39.220Z
2017-01-09T19:23:32.527Z
2017-01-09T19:23:32.527Z
Claris
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki#Replacing_the_nLockTime_field_entirely" rel="nofollow">BIP65</a> discusses replacing the <em>ntimelock</em> field with the new <code>CHECKLOCKTIMEVERIFY</code> OP code:</p>

<blockquote>
  <p>As an aside, note how if the SignatureHash() algorithm could optionally cover part of the scriptSig the signature could require that the scriptSig contain CHECKLOCKTIMEVERIFY opcodes, and additionally, require that they be executed. (the CODESEPARATOR opcode came very close to making this possible in v0.1 of Bitcoin) This per-signature capability could replace the per-transaction nLockTime field entirely as a valid signature would now be the proof that a transaction output can be spent.</p>
</blockquote>

<p>How is this different from the functionality of <em>ntimelock</em>? (I.e. Why would a signed transaction using <em>ntimelock</em> not be sufficient?)</p>

<transactions><protocol><checklocktimeverify>
BIP65: "replacing ntimelock entirely"?
Wizard Of Ozzie
# BIP65: "replacing ntimelock entirely"?

(Asked by: username_0 on 2015-07-07)

[BIP65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki#Replacing_the_nLockTime_field_entirely) discusses replacing the *ntimelock* field with the new `CHECKLOCKTIMEVERIFY` OP code:

> As an aside, note how if the SignatureHash() algorithm could optionally cover part of the scriptSig the signature could require that the scriptSig contain CHECKLOCKTIMEVERIFY opcodes, and additionally, require that they be executed. (the CODESEPARATOR opcode came very close to making this possible in v0.1 of Bitcoin) This per-signature capability could replace the per-transaction nLockTime field entirely as a valid signature would now be the proof that a transaction output can be spent.

How is this different from the functionality of *ntimelock*? (I.e. Why would a signed transaction using *ntimelock* not be sufficient?)

**Tags:** transactions, protocol, checklocktimeverify


---

## 1 answers

### Answer by username_1 on 2015-07-07. Score: 3

`nLockTime` affects transaction validity only, if you make a transaction with an `nLockTime` in the future (by block height or unix time) it is invalid until that time has been passed. This means that if you sign a locked transaction, you can also just as easily sign a different transaction spending the same outputs that is spendable today.

* This is useful if you wanted to make a contingency transaction and give it to a third party which spends the output to a charity if you aren't around to make use of it in a years time. If you are around you can spend it in an alternate way, if you aren't a third party can broadcast the locked transaction to the network once it has become valid.
* The limitation is in that you can't prove that funds are actually locked in this state, there's no way of knowing that the person won't just spend around an `nLockTime` transaction in a different way and bypass the restriction on when they could spend the funds. Setups are possible where a user sends an output to a new key, makes a locked transaction to themselves at another address, then destroys the private key, but this is incredibly flimsy and has no real assurances that the key wasn't retained secretly.

`CHECKLOCKTIMEVERIFY` is a new proposed opcode that allows you to use the current real time in a transaction script, allowing some more interesting and provable use cases that involve actually locking money rather than a particular transaction. This is closer behavior to how people normally think `nLockTime` should operate when they first hear about it.

* With CLTV, scripts that have different preconditions for spending based on the time are possible. Rather than limiting to a single presigned `nLockTime` transaction, a person could have every transaction in their wallet spendable by a specific charity key if 2 years pass without them being spent, or a 2-of-3 multisignature could have a contingency backdoor where an additional party can be included if the funds have not been used for an appreciable amount of time.
* CLTV also allows for payment channels to be used even with transaction malleability. A mutated transaction can break `nLockTime` refund transactions at any point, which makes them quite risky at present. With CLTV the payment channel transactions can just timeout and be refunded to the creator without the need for any further interaction.

BIP65 is potentially dangerous to end users as there are pretty much no take backs (if you lock your money for 5 years, there's no back doors or workarounds that will get your money back before then), but that said, that's a user interface problem rather than a fundamental security one. There's little contention about soft forking this change into the Bitcoin codebase in the future.

> **Comments:**
> **username_0**: So, if I'm understanding correctly, CTLV writes un-spendable UTXOs into the Blockchain (until the time limit is valid). What about ntimelock? These Txs wouldn't be written in as UTXOs, right?  
> **username_1**: Possibly, it depends how you use the CLTV opcode, it's just a switch you can use to decide spend-ability on. A nLockTime transaction is invalid before it is unlocked, a block that includes a transaction before its nLockTime is invalid as a consensus rule. They also can not be broadcast through the P2P network.  

---

