<p>As darosior says you can only impose a timelock such that Bitcoin can be spent <strong>after</strong> a certain block height. You can't impose a timelock such that Bitcoin can only be spent <strong>before</strong> a certain block height.</p>
<p>A related question is this <a href="https://bitcoin.stackexchange.com/questions/95879/with-miniscript-why-is-it-not-possible-to-invert-conditions-with-something-like">one</a> on the possibility of a <code>not()</code> condition in Miniscript. As Pieter Wuille stated in that answer:</p>
<blockquote>
<p>The nSequence and nLocktime fields themselves do observe time, and can only express larger-than constraints. Bitcoin transaction validity should be monotonic: once valid, absent double-spend, they remain valid.</p>
</blockquote>
<blockquote>
<p>The alternative would be a logistical nightmare. All mempool transactions would need to be reevaluated every block. Reasoning about validity of unconfirmed transactions would be a pain (e.g. what if you're paid using a tx spending the output of a soon-to-be expired tx?)</p>
</blockquote>

CC BY-SA 4.0
2020-12-07T11:21:38.873Z
2020-12-07T11:36:22.323Z
2020-12-07T11:36:22.323Z
Michael Folkson
<p>If the <code>nLockTime</code> is less than or equal to the next block height, it can be included in the next block.</p>
<p>To explicitly answer your questions:</p>
<ul>
<li>The <code>CLTV</code> op restricts the <code>nLockTime</code> field of the spending transaction, therefore if it is set in the past the condition is already fulfilled.</li>
<li>If the <code>nLockTime</code> field of a transaction is set to <code>500 000</code> it is valid to be included in any block which height is superior or equal to <code>500 000</code>.<br />
This basically means any block right now if there is no block chain reorganization deeper than <code>160 000</code> blocks :).</li>
</ul>
<p>This mechanism was cleverly used to discourage reorgs. <a href="https://github.com/bitcoin/bitcoin/pull/2340" rel="nofollow noreferrer">First introduced in the bitcoin-core wallet</a>, but now most wallets set the <code>nLockTime</code> field of their transactions to the next block.<br />
This prevents, in a future where miners would mainly be compensated for their work by transaction fees, a pernicious incentive to rollback the last block if it included a high fee-paying transaction.</p>

CC BY-SA 4.0
2020-12-07T11:16:17.200Z
2020-12-07T11:22:17.787Z
2020-12-07T11:22:17.787Z
Antoine Poinsot
<p>I just started learning about bitcoin scripting and wonder:</p>
<ul>
<li>what if the timelock in CLTV is in the past?</li>
<li>what if the timelock in nLocktime is equal to 500.000?</li>
</ul>

<bitcoin-core><consensus><timestamp><locktime>
what if the timelock is in the past?
Newdude
# what if the timelock is in the past?

(Asked by: username_0 on 2020-12-07)

I just started learning about bitcoin scripting and wonder:

* what if the timelock in CLTV is in the past?
* what if the timelock in nLocktime is equal to 500.000?

**Tags:** bitcoin-core, consensus, timestamp, locktime


---

## 2 answers

### Answer by username_2 on 2020-12-07. Score: 4 | Accepted answer

If the `nLockTime` is less than or equal to the next block height, it can be included in the next block.

To explicitly answer your questions:

* The `CLTV` op restricts the `nLockTime` field of the spending transaction, therefore if it is set in the past the condition is already fulfilled.
* If the `nLockTime` field of a transaction is set to `500 000` it is valid to be included in any block which height is superior or equal to `500 000`.  
  This basically means any block right now if there is no block chain reorganization deeper than `160 000` blocks :).

This mechanism was cleverly used to discourage reorgs. [First introduced in the bitcoin-core wallet](https://github.com/bitcoin/bitcoin/pull/2340), but now most wallets set the `nLockTime` field of their transactions to the next block.  
This prevents, in a future where miners would mainly be compensated for their work by transaction fees, a pernicious incentive to rollback the last block if it included a high fee-paying transaction.


---

### Answer by username_1 on 2020-12-07. Score: 1

As darosior says you can only impose a timelock such that Bitcoin can be spent **after** a certain block height. You can't impose a timelock such that Bitcoin can only be spent **before** a certain block height.

A related question is this [one](https://bitcoin.stackexchange.com/questions/95879/with-miniscript-why-is-it-not-possible-to-invert-conditions-with-something-like) on the possibility of a `not()` condition in Miniscript. As Pieter Wuille stated in that answer:

> The nSequence and nLocktime fields themselves do observe time, and can only express larger-than constraints. Bitcoin transaction validity should be monotonic: once valid, absent double-spend, they remain valid.

> The alternative would be a logistical nightmare. All mempool transactions would need to be reevaluated every block. Reasoning about validity of unconfirmed transactions would be a pain (e.g. what if you're paid using a tx spending the output of a soon-to-be expired tx?)


---

