<p>The <em>locktime</em> is a transaction field that can be used to prevent a transaction from being included in the blockchain until some point in the future.</p>
<p>If every input’s sequence number is set to the maximum <code>0xffffffff</code>, the locktime on the transaction is inactive. Regardless of the locktime value, the transaction can be included at any height.
If at least one sequence number in the transaction is <code>0xfffffffe</code> (MAX-1) or lower, a transaction’s locktime will be enforced per the following consensus rules:</p>
<p>If the locktime is less than 500,000,000, the locktime is interpreted as a block height. The locktime defines the greatest block height that <strong>cannot</strong> include the transaction¹. The transaction may be included in any block with a greater block height than its locktime.</p>
<p><em>Example: A transaction¹ has a locktime of 800,000. The transaction is invalid until block 800,000 but may be included in block 800,001 or any later block.</em></p>
<p>If the locktime is at least 500,000,000, the locktime is interpreted as a <a href="https://en.wikipedia.org/wiki/Unix_time" rel="nofollow noreferrer"><em>Unix time</em></a> (seconds since 00:00:00 UTC on 1 January 1970). A transaction may be included in a block if the <code>MedianTimePast</code> at the preceding block’s timestamp is greater than the locktime. The <code>MedianTimePast</code> refers to the median timestamp of the last eleven blocks.</p>
<p><em>Example: A transaction¹ has a locktime of 1,702,483,200 (i.e. 2023-12-13T16:00:00). Block 821023 (see table below) is the first block with a greater timestamp than this locktime, but only after a block is found where this timestamp is the median element of the most recent eleven blocks’ timestamps (including the new block), the transaction may be included in the following block. The considered transaction is valid for inclusion in block 821029 or later, as block 821023's timestamp is the median element of the timestamps from blocks 821018 through 821028 (both inclusive).</em></p>
<div class="s-table-container"><table class="s-table">
<thead>
<tr>
<th style="text-align: center;">Height</th>
<th style="text-align: center;">Timestamp</th>
<th style="text-align: center;">MTP</th>
<th style="text-align: center;">May include Tx</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: center;">821031</td>
<td style="text-align: center;">2023-12-13 17:45:16</td>
<td style="text-align: center;">2023-12-13 17:01:24</td>
<td style="text-align: center;">yes</td>
</tr>
<tr>
<td style="text-align: center;">821030</td>
<td style="text-align: center;">2023-12-13 17:35:38</td>
<td style="text-align: center;">2023-12-13 16:49:14</td>
<td style="text-align: center;">yes</td>
</tr>
<tr>
<td style="text-align: center;">821029</td>
<td style="text-align: center;">2023-12-13 17:35:24</td>
<td style="text-align: center;">2023-12-13 16:19:05</td>
<td style="text-align: center;"><strong>yes</strong></td>
</tr>
<tr>
<td style="text-align: center;">821028</td>
<td style="text-align: center;">2023-12-13 17:33:46</td>
<td style="text-align: center;"><strong>2023-12-13 16:02:03</strong></td>
<td style="text-align: center;">no</td>
</tr>
<tr>
<td style="text-align: center;">821027</td>
<td style="text-align: center;">2023-12-13 17:21:32</td>
<td style="text-align: center;">2023-12-13 15:56:00</td>
<td style="text-align: center;">no</td>
</tr>
<tr>
<td style="text-align: center;">821026</td>
<td style="text-align: center;">2023-12-13 17:01:24</td>
<td style="text-align: center;">2023-12-13 15:41:28</td>
<td style="text-align: center;">no</td>
</tr>
<tr>
<td style="text-align: center;">821025</td>
<td style="text-align: center;">2023-12-13 16:49:14</td>
<td style="text-align: center;">2023-12-13 15:29:58</td>
<td style="text-align: center;">no</td>
</tr>
<tr>
<td style="text-align: center;">821024</td>
<td style="text-align: center;">2023-12-13 16:19:05</td>
<td style="text-align: center;">2023-12-13 15:24:19</td>
<td style="text-align: center;">no</td>
</tr>
<tr>
<td style="text-align: center;">821023</td>
<td style="text-align: center;"><strong>2023-12-13 16:02:03</strong></td>
<td style="text-align: center;">2023-12-13 15:18:50</td>
<td style="text-align: center;">no</td>
</tr>
<tr>
<td style="text-align: center;">821022</td>
<td style="text-align: center;">2023-12-13 15:56:00</td>
<td style="text-align: center;">2023-12-13 15:10:06</td>
<td style="text-align: center;">no</td>
</tr>
<tr>
<td style="text-align: center;">821021</td>
<td style="text-align: center;">2023-12-13 15:41:28</td>
<td style="text-align: center;">2023-12-13 15:04:59</td>
<td style="text-align: center;">no</td>
</tr>
<tr>
<td style="text-align: center;">821020</td>
<td style="text-align: center;">2023-12-13 15:29:58</td>
<td style="text-align: center;">2023-12-13 14:59:44</td>
<td style="text-align: center;">no</td>
</tr>
<tr>
<td style="text-align: center;">821019</td>
<td style="text-align: center;">2023-12-13 15:24:19</td>
<td style="text-align: center;">2023-12-13 14:51:59</td>
<td style="text-align: center;">no</td>
</tr>
<tr>
<td style="text-align: center;">821018</td>
<td style="text-align: center;">2023-12-13 15:18:50</td>
<td style="text-align: center;">2023-12-13 14:28:53</td>
<td style="text-align: center;">no</td>
</tr>
<tr>
<td style="text-align: center;">821017</td>
<td style="text-align: center;">2023-12-13 15:10:06</td>
<td style="text-align: center;">2023-12-13 14:25:51</td>
<td style="text-align: center;">no</td>
</tr>
<tr>
<td style="text-align: center;">821016</td>
<td style="text-align: center;">2023-12-13 15:04:59</td>
<td style="text-align: center;">2023-12-13 14:21:23</td>
<td style="text-align: center;">no</td>
</tr>
</tbody>
</table></div>
<p>Since timestamps are only restricted to being greater than the MTP of the prior block and smaller than 2h into the future of the evaluating block’s network time, a sorted sequence of the timestamps may not necessarily have the same order as the corresponding blocks' heights.</p>
<hr />
<p><sub>¹A transaction is non-final if the locktime is active and not smaller than the current block height. From Bitcoin Core source code: <a href="https://github.com/bitcoin/bitcoin/blob/080a47cb8a8db27328bbdf57aa80cc4b4127a370/src/consensus/tx_verify.cpp#L17" rel="nofollow noreferrer">src/consensus/tx_verify.cpp:17–37</a></sub></p>
<pre><code>bool IsFinalTx(const CTransaction &amp;tx, int nBlockHeight, int64_t nBlockTime)
{
    if (tx.nLockTime == 0)
        return true;
    if ((int64_t)tx.nLockTime &lt; ((int64_t)tx.nLockTime &lt; LOCKTIME_THRESHOLD ? (int64_t)nBlockHeight : nBlockTime))
        return true;

    // Even if tx.nLockTime isn't satisfied by nBlockHeight/nBlockTime, a
    // transaction is still considered final if all inputs' nSequence ==
    // SEQUENCE_FINAL (0xffffffff), in which case nLockTime is ignored.
    //
    // Because of this behavior OP_CHECKLOCKTIMEVERIFY/CheckLockTime() will
    // also check that the spending input's nSequence != SEQUENCE_FINAL,
    // ensuring that an unsatisfied nLockTime value will actually cause
    // IsFinalTx() to return false here:
    for (const auto&amp; txin : tx.vin) {
        if (!(txin.nSequence == CTxIn::SEQUENCE_FINAL))
            return false;
    }
    return true;
}
</code></pre>
<p><sup>² As mentioned above, the example transactions must each have at least one sequence number lower than the maximum, or the locktime would not be active.</sup></p>

CC BY-SA 4.0
2023-12-13T18:28:33.957Z
2024-06-13T15:24:58.763Z
2024-06-13T15:24:58.763Z
Murch
<p>In order for the transaction to be final, i.e., not reversible, the transaction needs to be included in a block. The <code>nLockTime</code> parameter can be used to guarantee that the transaction cannot be mined prior to a certain block height or a certain unix time stamps. In other words, the protocol guarantees that a specific transaction cannot be finalized prior to a certain time.</p>

<p>Imagine that you deposit 1 BTC into a 2/2 multisignature account and you intend to use this to make incremental payments to some other party. One of the keys in the multisig account is held by you and another one is held by the other party. Each time you want to make a payment to the other party, you sign a transaction from the multisig to the other party and give the signature to them. The other party can then, at any time, choose to publish the transaction you just signed by adding their own signature and handing the transaction to miners, or they can wait to see if any more payments (i.e. signatures) come from you.</p>

<p>Before depositing the bitcoins to the multisig address, the other party should send you a signature of a transaction with <code>nLockTime</code> set to 1000 blocks in the future. This transaction transfers the entire deposit of 1 BTC back to you. If they do that, then you can always get your deposit back (after 1000 blocks) even if the other party for some reason dissapears or chooses to act destructively.</p>

<p>The parameter <code>nLockTime</code> makes it possible to create trust-free payment channels.</p>

CC BY-SA 4.0
2019-10-10T12:18:37.040Z
The payment channel I described here is the unidirectional payment channel that is explained in the first 10 minutes of this video:
https://www.youtube.com/watch?v=8zVzw912wPo
Thorkil Værge
CC BY-SA 4.0
2019-10-10T12:14:44.180Z
2019-10-10T12:14:44.180Z
Thorkil Værge
<p>From the wiki it basically states that you can make a transaction to another bitcoin address and add nlocktime. The way that this would work in real life would be if you get paid on salary and are paid bi-weekly, the bitcoins will be on the network but won't reach you until the nlocktime is up 
Edit: read example 1 from <a href="https://en.bitcoin.it/wiki/Contracts" rel="nofollow">https://en.bitcoin.it/wiki/Contracts</a></p>

CC BY-SA 3.0
2015-11-30T14:26:55.673Z
"The bitcoins will be on the network" is false. nLockTime'd transactions are not kept in the mempools of miners nor are they relayed between miners, until the nLockTime has almost elapsed. It is your responsibility to keep the signed transaction and publish it when the time is right.
dionyziz
CC BY-SA 3.0
2014-03-21T06:11:56.163Z
2014-03-21T06:11:56.163Z
rdadkins
<p>nLocktime is Time Locked Transaction, which means a transection cannot be verified until locked time passed.</p>
<p>you can take it as Future Date cheque (1st of next month) or Promise from friend to send you money next Monday. Now neither You receive funds or nor you can verify if funds are on the way until the time passed.</p>
<p>On Due Date might your cheque bounce or your friend make an ugly excuse. NLocktime allow double spending and Transaction with Nlocktime can't be verified by the nodes until time passed.</p>
<p>More Secure and trustless Time lock options are OP_CLTV and OP_CSV. They apply time lock on Script level, which means transection can be verified but script wont get verified until time passed.</p>
<p>This article helped me</p>
<p><a href="https://medium.com/summa-technology/bitcoins-time-locks-27e0c362d7a1" rel="nofollow noreferrer">https://medium.com/summa-technology/bitcoins-time-locks-27e0c362d7a1</a></p>

CC BY-SA 4.0
2021-06-24T04:25:00.910Z
2021-06-24T04:30:05.657Z
2021-06-24T04:30:05.657Z
Hina Zahoor
<p>I'm having a hard time understanding how nLockTime works. The <a href="https://en.bitcoin.it/wiki/NLockTime" rel="noreferrer">Bitcoin wiki</a> has an explanation that is confusing to me:</p>

<blockquote>
  <p>nLockTime is a parameter that can be attached to a transaction, that mandates a minimal time (specified in either unix time or block height), that before this time, the transaction cannot be accepted into a block.</p>
</blockquote>

<p>Can someone explain it in plain English, with an example?</p>

<transactions><locktime>
Can someone explain nLockTime?
gak
# Can someone explain nLockTime?

(Asked by: username_0 on 2014-03-21)

I'm having a hard time understanding how nLockTime works. The [Bitcoin wiki](https://en.bitcoin.it/wiki/NLockTime) has an explanation that is confusing to me:

> nLockTime is a parameter that can be attached to a transaction, that mandates a minimal time (specified in either unix time or block height), that before this time, the transaction cannot be accepted into a block.

Can someone explain it in plain English, with an example?

**Tags:** transactions, locktime


---

## 4 answers

### Answer by username_1 on 2023-12-13. Score: 5

The *locktime* is a transaction field that can be used to prevent a transaction from being included in the blockchain until some point in the future.

If every input’s sequence number is set to the maximum `0xffffffff`, the locktime on the transaction is inactive. Regardless of the locktime value, the transaction can be included at any height.
If at least one sequence number in the transaction is `0xfffffffe` (MAX-1) or lower, a transaction’s locktime will be enforced per the following consensus rules:

If the locktime is less than 500,000,000, the locktime is interpreted as a block height. The locktime defines the greatest block height that **cannot** include the transaction¹. The transaction may be included in any block with a greater block height than its locktime.

*Example: A transaction¹ has a locktime of 800,000. The transaction is invalid until block 800,000 but may be included in block 800,001 or any later block.*

If the locktime is at least 500,000,000, the locktime is interpreted as a [*Unix time*](https://en.wikipedia.org/wiki/Unix_time) (seconds since 00:00:00 UTC on 1 January 1970). A transaction may be included in a block if the `MedianTimePast` at the preceding block’s timestamp is greater than the locktime. The `MedianTimePast` refers to the median timestamp of the last eleven blocks.

*Example: A transaction¹ has a locktime of 1,702,483,200 (i.e. 2023-12-13T16:00:00). Block 821023 (see table below) is the first block with a greater timestamp than this locktime, but only after a block is found where this timestamp is the median element of the most recent eleven blocks’ timestamps (including the new block), the transaction may be included in the following block. The considered transaction is valid for inclusion in block 821029 or later, as block 821023's timestamp is the median element of the timestamps from blocks 821018 through 821028 (both inclusive).*

| Height | Timestamp | MTP | May include Tx |
| --- | --- | --- | --- |
| 821031 | 2023-12-13 17:45:16 | 2023-12-13 17:01:24 | yes |
| 821030 | 2023-12-13 17:35:38 | 2023-12-13 16:49:14 | yes |
| 821029 | 2023-12-13 17:35:24 | 2023-12-13 16:19:05 | **yes** |
| 821028 | 2023-12-13 17:33:46 | **2023-12-13 16:02:03** | no |
| 821027 | 2023-12-13 17:21:32 | 2023-12-13 15:56:00 | no |
| 821026 | 2023-12-13 17:01:24 | 2023-12-13 15:41:28 | no |
| 821025 | 2023-12-13 16:49:14 | 2023-12-13 15:29:58 | no |
| 821024 | 2023-12-13 16:19:05 | 2023-12-13 15:24:19 | no |
| 821023 | **2023-12-13 16:02:03** | 2023-12-13 15:18:50 | no |
| 821022 | 2023-12-13 15:56:00 | 2023-12-13 15:10:06 | no |
| 821021 | 2023-12-13 15:41:28 | 2023-12-13 15:04:59 | no |
| 821020 | 2023-12-13 15:29:58 | 2023-12-13 14:59:44 | no |
| 821019 | 2023-12-13 15:24:19 | 2023-12-13 14:51:59 | no |
| 821018 | 2023-12-13 15:18:50 | 2023-12-13 14:28:53 | no |
| 821017 | 2023-12-13 15:10:06 | 2023-12-13 14:25:51 | no |
| 821016 | 2023-12-13 15:04:59 | 2023-12-13 14:21:23 | no |

Since timestamps are only restricted to being greater than the MTP of the prior block and smaller than 2h into the future of the evaluating block’s network time, a sorted sequence of the timestamps may not necessarily have the same order as the corresponding blocks' heights.

---

¹A transaction is non-final if the locktime is active and not smaller than the current block height. From Bitcoin Core source code: [src/consensus/tx\_verify.cpp:17–37](https://github.com/bitcoin/bitcoin/blob/080a47cb8a8db27328bbdf57aa80cc4b4127a370/src/consensus/tx_verify.cpp#L17)

```
bool IsFinalTx(const CTransaction &tx, int nBlockHeight, int64_t nBlockTime)
{
    if (tx.nLockTime == 0)
        return true;
    if ((int64_t)tx.nLockTime < ((int64_t)tx.nLockTime < LOCKTIME_THRESHOLD ? (int64_t)nBlockHeight : nBlockTime))
        return true;

    // Even if tx.nLockTime isn't satisfied by nBlockHeight/nBlockTime, a
    // transaction is still considered final if all inputs' nSequence ==
    // SEQUENCE_FINAL (0xffffffff), in which case nLockTime is ignored.
    //
    // Because of this behavior OP_CHECKLOCKTIMEVERIFY/CheckLockTime() will
    // also check that the spending input's nSequence != SEQUENCE_FINAL,
    // ensuring that an unsatisfied nLockTime value will actually cause
    // IsFinalTx() to return false here:
    for (const auto& txin : tx.vin) {
        if (!(txin.nSequence == CTxIn::SEQUENCE_FINAL))
            return false;
    }
    return true;
}

```

² As mentioned above, the example transactions must each have at least one sequence number lower than the maximum, or the locktime would not be active.


---

### Answer by username_2 on 2019-10-10. Score: 2

In order for the transaction to be final, i.e., not reversible, the transaction needs to be included in a block. The `nLockTime` parameter can be used to guarantee that the transaction cannot be mined prior to a certain block height or a certain unix time stamps. In other words, the protocol guarantees that a specific transaction cannot be finalized prior to a certain time.

Imagine that you deposit 1 BTC into a 2/2 multisignature account and you intend to use this to make incremental payments to some other party. One of the keys in the multisig account is held by you and another one is held by the other party. Each time you want to make a payment to the other party, you sign a transaction from the multisig to the other party and give the signature to them. The other party can then, at any time, choose to publish the transaction you just signed by adding their own signature and handing the transaction to miners, or they can wait to see if any more payments (i.e. signatures) come from you.

Before depositing the bitcoins to the multisig address, the other party should send you a signature of a transaction with `nLockTime` set to 1000 blocks in the future. This transaction transfers the entire deposit of 1 BTC back to you. If they do that, then you can always get your deposit back (after 1000 blocks) even if the other party for some reason dissapears or chooses to act destructively.

The parameter `nLockTime` makes it possible to create trust-free payment channels.

> **Comments:**
> **username_2**: The payment channel I described here is the unidirectional payment channel that is explained in the first 10 minutes of this video: https://www.youtube.com/watch?v=8zVzw912wPo  

---

### Answer by username_3 on 2014-03-21. Score: 2

From the wiki it basically states that you can make a transaction to another bitcoin address and add nlocktime. The way that this would work in real life would be if you get paid on salary and are paid bi-weekly, the bitcoins will be on the network but won't reach you until the nlocktime is up
Edit: read example 1 from <https://en.bitcoin.it/wiki/Contracts>

> **Comments:**
> **username_4**: "The bitcoins will be on the network" is false. nLockTime'd transactions are not kept in the mempools of miners nor are they relayed between miners, until the nLockTime has almost elapsed. It is your responsibility to keep the signed transaction and publish it when the time is right.  

---

### Answer by username_5 on 2021-06-24. Score: 0

nLocktime is Time Locked Transaction, which means a transection cannot be verified until locked time passed.

you can take it as Future Date cheque (1st of next month) or Promise from friend to send you money next Monday. Now neither You receive funds or nor you can verify if funds are on the way until the time passed.

On Due Date might your cheque bounce or your friend make an ugly excuse. NLocktime allow double spending and Transaction with Nlocktime can't be verified by the nodes until time passed.

More Secure and trustless Time lock options are OP\_CLTV and OP\_CSV. They apply time lock on Script level, which means transection can be verified but script wont get verified until time passed.

This article helped me

<https://medium.com/summa-technology/bitcoins-time-locks-27e0c362d7a1>


---

