NLockTime: Difference between revisions
Jump to navigation
Jump to search
This page was erroneously attributing sequence lock time mechanics to the lock time. Fixed, and expanded regarding BIP 113. |
emphasise it's at-or-after |
||
Line 4: | Line 4: | ||
* If <code>nLockTime < 500000000</code> | * If <code>nLockTime < 500000000</code> | ||
** Specifies the block number at which this transaction can be spent. | ** Specifies the block number at (or after) which this transaction can be spent. | ||
* Otherwise | * Otherwise | ||
** Specifies the UNIX timestamp at which this transaction can be spent. | ** Specifies the UNIX timestamp at (or after) 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. | 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. |
Revision as of 14:51, 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 (or after) which this transaction can be spent.
- Otherwise
- Specifies the UNIX timestamp at (or after) 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
- lock_time in the protocol specification
- Timelock
- BIP113
- The CHECKLOCKTIMEVERIFY opcode in BIP65