NLockTime: Difference between revisions

From Bitcoin Wiki
Jump to navigation Jump to search
Darosior (talk | contribs)
Add more details about the lock time interpretation.
MarkBLundeberg (talk | contribs)
This page was erroneously attributing sequence lock time mechanics to the lock time. Fixed, and expanded regarding BIP 113.
Line 3: Line 3:
'''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, then nLockTime is ignored.
'''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, then nLockTime is ignored.


Since [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68], the lock time can either be absolute or relative. Given a transaction,
* If <code>nLockTime < 500000000</code>
* If the most significant bit (<code>1<<31</code>) of the '''nLockTime''' field is set (if the lock time is absolute)
** Specifies the block number at which this transaction can be spent.
** If <code>nLockTime < 500000000</code>
* Otherwise
*** Specifies the block number at which this transaction can be spent
** Specifies the UNIX timestamp at which this transaction can be spent.
** Otherwise
 
*** Specifies the UNIX timestamp at which this transaction can be spent
Note that since the adoption of BIP 113, the time-based nLockTime is compared to the 11-block [[median time past]], 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.
* Otherwise (if the lock time is relative)
** If the 23rd bit (<code>1<<22</code>) is not set
*** The last 16 bits of the '''nLockTime''' field specify a relative time in units of 512 seconds. The transaction can only be included in a block if <code>spending_tx_block_time > spent_tx_block_time + nLockTime * 512</code>.
** Otherwise
*** The last 16 bits of the '''nLockTime''' field specify a relative block height before which the transaction can not be included in a block. In other words it can be included if <code>spending_tx_block_height > spent_tx_block_height + nLockTime</code>


==See Also==
==See Also==
* lock_time in [[Protocol_specification#tx|the protocol specification]]
* lock_time in [[Protocol_specification#tx|the protocol specification]]
* [[Timelock]]
* [[Timelock]]
* [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68]
* [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]
* The CHECKLOCKTIMEVERIFY opcode in [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP65]
* The CHECKSEQUENCEVERIFY opcode in [https://github.com/bitcoin/bips/blob/master/bip-00112.mediawiki BIP112]


[[Category:Technical]]
[[Category:Technical]]
{{lowercase}}
{{lowercase}}

Revision as of 14:48, 24 October 2019

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, then nLockTime is ignored.

  • If nLockTime < 500000000
    • Specifies the block number at which this transaction can be spent.
  • Otherwise
    • Specifies the UNIX timestamp at which this transaction can be spent.

Note that since the adoption of BIP 113, the time-based nLockTime is compared to the 11-block median time past, 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.

See Also