<blockquote>
  <p>Say that currently, the block height is 377199. If I wanted to send money to someone, but only have them receive it at some time in the future, then I could make a transaction to their address, set the locktime to 400000 and set all sequence numbers in the transaction to 0xffffffff. This transaction will get mined into block 377200 or maybe 377201.</p>
</blockquote>

<p><code>nLockTime</code> makes a transaction <strong>invalid</strong> not <em>unspendable</em>. If you attempt to broadcast a transaction before it is valid, it will not be relayed, and is not able to be included in any block. You can retain the transaction until it becomes valid (by block height or time), but you can also spend the original outputs with a completely different transaction in the mean time. For your example it will not make it into a block until at least height 400,000, and only if you broadcast it after that time. <code>nLockTime</code> does not affect the spendability of the output in the blocks, just the validity of the transaction that creates them. </p>

CC BY-SA 3.0
2015-10-05T00:21:57.730Z
but if all sequence numbers are `0xffffffff` then the transaction will be "final" [and will get mined into a block.](https://github.com/bitcoin/bitcoin/blob/5b77244c60f3137647fed1c9510965d48992ccbe/src/miner.cpp#L165)
mulllhausen
CC BY-SA 3.0
2015-10-05T00:25:46.173Z
In which case the `nLockTime` will have no effect whatsoever.
Claris
CC BY-SA 3.0
2015-10-05T00:36:00.220Z
ah right. do you know where i can verify this in the source code?
mulllhausen
CC BY-SA 3.0
2015-10-05T11:36:58.850Z
the rules might be found in [ConnectBlock](https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L1684)?
mulllhausen
CC BY-SA 3.0
2015-10-04T22:12:36.137Z
2016-08-14T10:09:34.007Z
2016-08-14T10:09:34.007Z
Claris
<p>I have been trying to understand locktimes and sequence numbers. I'm gradually building up a picture in my head based on code, code comments and info on the web. Rather than asking lots of questions, I am going to describe my understanding of how locktime and sequence numbers work. Please could someone tell me if it is correct, and if not then please specify <strong>exactly</strong> which bits are wrong, using examples or pointing me to the source code.</p>

<h3>Mining criteria</h3>

<p><a href="https://en.bitcoin.it/wiki/Protocol_documentation#tx" rel="nofollow noreferrer">All transactions inputs have their own sequence number, and there is one locktime for the whole transaction.</a> <a href="https://github.com/bitcoin/bitcoin/blob/4899a04c24b927166048a74999992d216a543c23/src/main.cpp#L641-L651" rel="nofollow noreferrer">A transaction can be made "final" by</a>:</p>

<ul>
<li>setting the locktime to 0, or</li>
<li>setting the locktime to be less than the current block height, or</li>
<li>setting the locktime to be less than the current time (but still above a threshold so that it is not confused for a block height), or</li>
<li>setting ALL txin sequence numbers to <code>0xffffffff</code>.</li>
</ul>

<p>Any one of these conditions is sufficient for a transaction to be considered "final". If all conditions fail then the transaction is not "final". <a href="https://github.com/bitcoin/bitcoin/blob/5b77244c60f3137647fed1c9510965d48992ccbe/src/miner.cpp#L165" rel="nofollow noreferrer">Only "final" transactions get mined into blocks - non final transactions never make it to the blockchain.</a> Note that the only way that a transaction in the blockchain can contain a locktime with a future timestamp or future block number is if all sequence numbers are set to <code>0xffffffff</code>.</p>

<h3>Locking funds</h3>

<p>Say that currently, the block height is <code>377199</code>. If I wanted to send money to someone, but only have them receive it at some time in the future, then I could make a transaction to their address, set the locktime to <code>400000</code> and set all sequence numbers in the transaction to <code>0xffffffff</code>. This transaction will get mined into block <code>377200</code> or maybe <code>377201</code>. It will also probably require a mining fee. This fee will be part of the coinbase funds and is deducted immediately from the previous transaction being spent (ie. the miner does not have to wait until the locktime to put the funds in the coinbase).</p>

<p>All txin scripts in my <em>locktime=400000</em> transaction must successfully validate against their corresponding txout scripts in the transaction(s) being spent. Once the <em>locktime=400000</em> transaction has been mined into a block (say <em>block=377200</em>) then any block built on top of <em>block=377200</em> cannot double-spend the txouts that my <em>locktime=400000</em> transaction has already spent. As soon as the <em>locktime=400000</em> transaction is mined into a block this causes the UTXOs it references to be immediately removed from the pool, even though the funds are locked away for a period until the locktime is reached.</p>

<h3>Spending locked funds</h3>

<p>Not all transaction outputs that have been mined into a block can be spent immediately or even at all. For one thing, if transaction A is spent by transaction B then the txout scripts in transaction B are <a href="https://bitcoin.stackexchange.com/a/38009/2116">not verified for syntax by the miners</a> (though the txout scripts in A are verified). If the txout scripts in B are nonsense then the funds they direct will become forever unspendable.</p>

<p>But in a case where the scriptsig and scriptpubkey do validate, miners will only permit a transaction into the blockchain if it satisfies the locktime criteria. Say someone wishes to spend the <em>locktime=400000</em> transaction funds (already mined into block) - they would construct a transaction of their own that uses the txouts from the <em>locktime=400000</em> transaction, and broadcast it to the network. Miners would perform all the standard checks on this new transaction, and the specific checks relating to the locktime would be:</p>

<ul>
<li>that the transaction is "final", as discussed before</li>
<li>that this latest block being created is 400000 or greater</li>
</ul>

<p>If this latest block is not 400000 then the transaction cannot be mined into the block. And infact if a rogue miner does go and put the spending transaction into a block before block 400000 then this block will be rejected by other miners on the network for containing a transaction that fails to validate.</p>

<p>Say the person spending the <em>locktime=400000</em> transaction funds wants this to happen as soon as block 400000 is reached. If they broadcast their spending transaction too early (eg 377199) then it may get rejected as miners discard the transaction for not validating. If the miners are smart (they probably are but I haven't looked at the code for this) then they will see that the transaction will become spendable at a date in the future, and will hold on to it so that they can mine it into block 400000 and get the fees before everybody else. However if the transaction is too far in the future then the miners may run out of memory to store this transaction and discard it. The person issuing the transaction can check its propagation on blockchain.info and re-broadcast it before block 400000 if propagation is too low.</p>

<h3>OP_CHECKLOCKTIMEVERIFY</h3>

<p>This opcode can be used in either scriptpubkey or scriptsig (or both at once). It basically compares a stack item (<a href="https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L367" rel="nofollow noreferrer">only the rightmost 5 bytes in minimized format</a>) with the transaction's locktime. If the transaction locktime (<a href="https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1138-L1141" rel="nofollow noreferrer">timestamp when above the threshold or block number when below the threshold</a>) <a href="https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1146-L1147" rel="nofollow noreferrer">is <strong>greater</strong> than the stack item then this opcode will validate successfully. But if the transaction locktime has not yet reached the stack item value then the opcode will fail to validate and miners will not include this transaction in a block.</a></p>

<p>In the case where a script contains <code>OP_CHECKLOCKTIMEVERIFY</code> but the sequence number for that script's txin is <code>0xffffff</code> then this means that the locktime is being ignored. <a href="https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1159" rel="nofollow noreferrer">Therefore <code>OP_CHECKLOCKTIMEVERIFY</code> will fail</a> and the transaction will not be mined into a block.</p>

<p><code>OP_CHECKLOCKTIMEVERIFY</code> can also be used to make sure funds cannot be accessed until a future date or block. For example to send funds to address xyz but make them accessible at block 400000 or later, the following txout script could be used:</p>

<pre><code>OP_DUP OP_HASH160 OP_PUSHDATA xyz OP_EQUALVERIFY OP_CHECKSIG OP_PUSHDATA 400000 OP_CHECKLOCKTIMEVERIFY
</code></pre>

<p>Then to spend this transaction, someone will need to submit a transaction containing locktime 400000 or greater (but still below the threshold).</p>

<locktime><sequence><checklocktimeverify>
Is my understanding of locktime correct?
mulllhausen
# Is my understanding of locktime correct?

(Asked by: username_0 on 2015-10-04)

I have been trying to understand locktimes and sequence numbers. I'm gradually building up a picture in my head based on code, code comments and info on the web. Rather than asking lots of questions, I am going to describe my understanding of how locktime and sequence numbers work. Please could someone tell me if it is correct, and if not then please specify **exactly** which bits are wrong, using examples or pointing me to the source code.

### Mining criteria

[All transactions inputs have their own sequence number, and there is one locktime for the whole transaction.](https://en.bitcoin.it/wiki/Protocol_documentation#tx) [A transaction can be made "final" by](https://github.com/bitcoin/bitcoin/blob/4899a04c24b927166048a74999992d216a543c23/src/main.cpp#L641-L651):

* setting the locktime to 0, or
* setting the locktime to be less than the current block height, or
* setting the locktime to be less than the current time (but still above a threshold so that it is not confused for a block height), or
* setting ALL txin sequence numbers to `0xffffffff`.

Any one of these conditions is sufficient for a transaction to be considered "final". If all conditions fail then the transaction is not "final". [Only "final" transactions get mined into blocks - non final transactions never make it to the blockchain.](https://github.com/bitcoin/bitcoin/blob/5b77244c60f3137647fed1c9510965d48992ccbe/src/miner.cpp#L165) Note that the only way that a transaction in the blockchain can contain a locktime with a future timestamp or future block number is if all sequence numbers are set to `0xffffffff`.

### Locking funds

Say that currently, the block height is `377199`. If I wanted to send money to someone, but only have them receive it at some time in the future, then I could make a transaction to their address, set the locktime to `400000` and set all sequence numbers in the transaction to `0xffffffff`. This transaction will get mined into block `377200` or maybe `377201`. It will also probably require a mining fee. This fee will be part of the coinbase funds and is deducted immediately from the previous transaction being spent (ie. the miner does not have to wait until the locktime to put the funds in the coinbase).

All txin scripts in my *locktime=400000* transaction must successfully validate against their corresponding txout scripts in the transaction(s) being spent. Once the *locktime=400000* transaction has been mined into a block (say *block=377200*) then any block built on top of *block=377200* cannot double-spend the txouts that my *locktime=400000* transaction has already spent. As soon as the *locktime=400000* transaction is mined into a block this causes the UTXOs it references to be immediately removed from the pool, even though the funds are locked away for a period until the locktime is reached.

### Spending locked funds

Not all transaction outputs that have been mined into a block can be spent immediately or even at all. For one thing, if transaction A is spent by transaction B then the txout scripts in transaction B are [not verified for syntax by the miners](https://bitcoin.stackexchange.com/a/38009/2116) (though the txout scripts in A are verified). If the txout scripts in B are nonsense then the funds they direct will become forever unspendable.

But in a case where the scriptsig and scriptpubkey do validate, miners will only permit a transaction into the blockchain if it satisfies the locktime criteria. Say someone wishes to spend the *locktime=400000* transaction funds (already mined into block) - they would construct a transaction of their own that uses the txouts from the *locktime=400000* transaction, and broadcast it to the network. Miners would perform all the standard checks on this new transaction, and the specific checks relating to the locktime would be:

* that the transaction is "final", as discussed before
* that this latest block being created is 400000 or greater

If this latest block is not 400000 then the transaction cannot be mined into the block. And infact if a rogue miner does go and put the spending transaction into a block before block 400000 then this block will be rejected by other miners on the network for containing a transaction that fails to validate.

Say the person spending the *locktime=400000* transaction funds wants this to happen as soon as block 400000 is reached. If they broadcast their spending transaction too early (eg 377199) then it may get rejected as miners discard the transaction for not validating. If the miners are smart (they probably are but I haven't looked at the code for this) then they will see that the transaction will become spendable at a date in the future, and will hold on to it so that they can mine it into block 400000 and get the fees before everybody else. However if the transaction is too far in the future then the miners may run out of memory to store this transaction and discard it. The person issuing the transaction can check its propagation on blockchain.info and re-broadcast it before block 400000 if propagation is too low.

### OP\_CHECKLOCKTIMEVERIFY

This opcode can be used in either scriptpubkey or scriptsig (or both at once). It basically compares a stack item ([only the rightmost 5 bytes in minimized format](https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L367)) with the transaction's locktime. If the transaction locktime ([timestamp when above the threshold or block number when below the threshold](https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1138-L1141)) [is **greater** than the stack item then this opcode will validate successfully. But if the transaction locktime has not yet reached the stack item value then the opcode will fail to validate and miners will not include this transaction in a block.](https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1146-L1147)

In the case where a script contains `OP_CHECKLOCKTIMEVERIFY` but the sequence number for that script's txin is `0xffffff` then this means that the locktime is being ignored. [Therefore `OP_CHECKLOCKTIMEVERIFY` will fail](https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1159) and the transaction will not be mined into a block.

`OP_CHECKLOCKTIMEVERIFY` can also be used to make sure funds cannot be accessed until a future date or block. For example to send funds to address xyz but make them accessible at block 400000 or later, the following txout script could be used:

```
OP_DUP OP_HASH160 OP_PUSHDATA xyz OP_EQUALVERIFY OP_CHECKSIG OP_PUSHDATA 400000 OP_CHECKLOCKTIMEVERIFY

```

Then to spend this transaction, someone will need to submit a transaction containing locktime 400000 or greater (but still below the threshold).

**Tags:** locktime, sequence, checklocktimeverify


---

## 1 answers

### Answer by username_1 on 2015-10-04. Score: 3

> Say that currently, the block height is 377199. If I wanted to send money to someone, but only have them receive it at some time in the future, then I could make a transaction to their address, set the locktime to 400000 and set all sequence numbers in the transaction to 0xffffffff. This transaction will get mined into block 377200 or maybe 377201.

`nLockTime` makes a transaction **invalid** not *unspendable*. If you attempt to broadcast a transaction before it is valid, it will not be relayed, and is not able to be included in any block. You can retain the transaction until it becomes valid (by block height or time), but you can also spend the original outputs with a completely different transaction in the mean time. For your example it will not make it into a block until at least height 400,000, and only if you broadcast it after that time. `nLockTime` does not affect the spendability of the output in the blocks, just the validity of the transaction that creates them.

> **Comments:**
> **username_0**: but if all sequence numbers are `0xffffffff` then the transaction will be "final" [and will get mined into a block.](https://github.com/bitcoin/bitcoin/blob/5b77244c60f3137647fed1c9510965d48992ccbe/src/miner.cpp#L165)  
> **username_1**: In which case the `nLockTime` will have no effect whatsoever.  
> **username_0**: ah right. do you know where i can verify this in the source code?  
> **username_0**: the rules might be found in [ConnectBlock](https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L1684)?  

---

