NLockTime: Difference between revisions
Clarified the use of lock times. |
NotATether (talk | contribs) m Add reference |
||
| (13 intermediate revisions by 6 users not shown) | |||
| Line 1: | Line 1: | ||
{{stub}} | {{stub}} | ||
nLockTime is a parameter of a transaction, that, if any input indicates so (by having nSequence not equal to UINT_MAX), mandates a minimal time (specified in either unix time or block height), | '''nLockTime''' is a parameter of a transaction, that, if any input indicates so (by having nSequence not equal to UINT_MAX), mandates a minimal time (specified in either unix time or block height), before which the transaction cannot be accepted into a block. If all inputs in a transaction have nSequence equal to UINT_MAX (0xFFFFFFFF), then nLockTime is ignored. | ||
See lock_time in [[Protocol_specification#tx|the protocol specification]] | * If <code>nLockTime < 500000000</code> | ||
** Specifies the block number after which this transaction can be included in a block. | |||
* Otherwise | |||
** Specifies the UNIX timestamp after which this transaction can be included in a block. | |||
Note that since the adoption of BIP 113, the time-based nLockTime is compared to the 11-block [[median time past]] (the median timestamp of the 11 blocks preceding the block in which the transaction is mined), and not the block time itself. The median time past tends to lag the current unix time by about one hour (give or take), but unlike block time it increases monotonically. | |||
For transaction relay, nLockTime must be <= the current block's height (block-based) or <= the current median time past (if time based). This ensures that the transaction can be included in the next block. | |||
The behavior of a transaction's nLockTime can be modified by the sequence number of an input when using [[Script#Locktime|OP_CHECKSEQUENCEVERIFY]]. That particular opcode is used inside input scripts to assert that the input's sequence number, which in normal transactions is set to UINT_MAX, is greater than or equal to the top item of the stack (usually the transaction's nLockTime<ref>https://bitcoin.stackexchange.com/questions/38845/what-does-op-checksequenceverify-op-csv-do</ref>). OP_CHECKSEQUENCEVERIFY is used in some proposed Layer 2 protocols, such as eltoo<ref>https://blockstream.com/eltoo.pdf</ref>. | |||
==See Also== | |||
* lock_time in [[Protocol_specification#tx|the protocol specification]] | |||
* [[Transaction]] | |||
* [[Timelock]] | |||
* [https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki BIP113] | |||
* The CHECKLOCKTIMEVERIFY opcode in [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65] | |||
==References== | |||
[[Category:Technical]] | [[Category:Technical]] | ||
{{lowercase}} | |||
Latest revision as of 07:15, 17 February 2022
This page is a stub. Help by expanding it.
nLockTime is a parameter of a transaction, that, if any input indicates so (by having nSequence not equal to UINT_MAX), mandates a minimal time (specified in either unix time or block height), before which the transaction cannot be accepted into a block. If all inputs in a transaction have nSequence equal to UINT_MAX (0xFFFFFFFF), then nLockTime is ignored.
- If
nLockTime < 500000000- Specifies the block number after which this transaction can be included in a block.
- Otherwise
- Specifies the UNIX timestamp after which this transaction can be included in a block.
Note that since the adoption of BIP 113, the time-based nLockTime is compared to the 11-block median time past (the median timestamp of the 11 blocks preceding the block in which the transaction is mined), and not the block time itself. The median time past tends to lag the current unix time by about one hour (give or take), but unlike block time it increases monotonically.
For transaction relay, nLockTime must be <= the current block's height (block-based) or <= the current median time past (if time based). This ensures that the transaction can be included in the next block.
The behavior of a transaction's nLockTime can be modified by the sequence number of an input when using OP_CHECKSEQUENCEVERIFY. That particular opcode is used inside input scripts to assert that the input's sequence number, which in normal transactions is set to UINT_MAX, is greater than or equal to the top item of the stack (usually the transaction's nLockTime[1]). OP_CHECKSEQUENCEVERIFY is used in some proposed Layer 2 protocols, such as eltoo[2].
See Also
- lock_time in the protocol specification
- Transaction
- Timelock
- BIP113
- The CHECKLOCKTIMEVERIFY opcode in BIP65
References