transactions – Can somebody clarify nLockTime?

The locktime is a transaction discipline that can be utilized to stop a transaction from being included within the blockchain till some level sooner or later.

If each enter’s sequence quantity is ready to the utmost 0xffffffff, the locktime on the transaction is inactive. Whatever the locktime worth, the transaction might be included at any peak.
If no less than one sequence quantity within the transaction is 0xfffffffe (MAX-1) or decrease, a transaction’s locktime can be enforced per the next consensus guidelines:

If the locktime is lower than 500,000,000, the locktime is interpreted as a block peak. The locktime defines the best block peak that can’t embrace the transaction¹. The transaction could also be included in any block with a higher block peak than its locktime.

Instance: A transaction¹ has a locktime of 800,000. The transaction is invalid till block 800,000 however could also be included in block 800,001 or any later block.

If the locktime is no less than 500,000,000, the locktime is interpreted as a Unix time (seconds since 00:00:00 UTC on 1 January 1970). A transaction could also be included in a block if the MedianTimePast on the previous block’s timestamp is bigger than the locktime. The MedianTimePast refers back to the median timestamp of the final eleven blocks.

Instance: A transaction¹ has a locktime of 1,702,483,200 (i.e. 2023-12-13T16:00:00). Block 821023 (see desk beneath) is the primary block with a higher timestamp than this locktime, however solely after a block is discovered the place this timestamp is the median factor of the newest eleven blocks’ timestamps (together with the brand new block), the transaction could also be included within the following block. The thought-about transaction is legitimate for inclusion in block 821029 or later, as block 821023’s timestamp is the median factor of the timestamps from blocks 821018 by way of 821028 (each inclusive).

Since timestamps are solely restricted to being higher than the MTP of the prior block and smaller than 2h into the way forward for the evaluating block’s community time, a sorted sequence of the timestamps might not essentially have the identical order because the corresponding blocks’ heights.

_{¹A transaction is non-final if the locktime is lively and never smaller than the present block peak. From Bitcoin Core supply code: src/consensus/tx_verify.cpp:17–37}

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 when tx.nLockTime is not happy by nBlockHeight/nBlockTime, a
    // transaction remains to be thought-about closing if all inputs' nSequence ==
    // SEQUENCE_FINAL (0xffffffff), through which case nLockTime is ignored.
    //
    // Due to this habits OP_CHECKLOCKTIMEVERIFY/CheckLockTime() will
    // additionally examine that the spending enter's nSequence != SEQUENCE_FINAL,
    // guaranteeing that an unhappy nLockTime worth will truly trigger
    // IsFinalTx() to return false right here:
    for (const auto& txin : tx.vin) {
        if (!(txin.nSequence == CTxIn::SEQUENCE_FINAL))
            return false;
    }
    return true;
}

^{² As talked about above, the instance transactions should every have no less than one sequence quantity decrease than the utmost, or the locktime wouldn’t be lively.}