transactions – Can somebody clarify nLockTime?

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

If each enter’s sequence quantity is about to the utmost 0xffffffff, the locktime on the transaction is inactive. Whatever the locktime worth, the transaction could be included at any top.
If at the very least one sequence quantity within the transaction is 0xfffffffe (MAX-1) or decrease, a transaction’s locktime will probably be enforced per the next consensus guidelines:

If the locktime is lower than 500,000,000, the locktime is interpreted as a block top. The locktime defines the best block top that can not embrace the transaction¹. The transaction could also be included in any block with a higher block top 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 at the very least 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 ingredient of the newest eleven blocks’ timestamps (together with the brand new block), the transaction could also be included within the following block. The thought of transaction is legitimate for inclusion in block 821029 or later, as block 821023’s timestamp is the median ingredient of the timestamps from blocks 821018 via 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 energetic and never smaller than the present block top. 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 continues to be thought of last if all inputs' nSequence ==
    // SEQUENCE_FINAL (0xffffffff), during which case nLockTime is ignored.
    //
    // Due to this habits OP_CHECKLOCKTIMEVERIFY/CheckLockTime() will
    // additionally test that the spending enter's nSequence != SEQUENCE_FINAL,
    // guaranteeing that an unhappy nLockTime worth will really 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 at the very least one sequence quantity decrease than the utmost, or the locktime wouldn’t be energetic.}