Interaction with nSequence

Setting a value in the nLockTime field is not enough to lock a transaction. For the lock to be enforced by the network's consensus rules, it must interact with the nSequence field of the transaction's inputs.

1. The "Finality" Override

A transaction is considered "final" (immediately mineable) if all of its inputs have an nSequence value of 0xffffffff.

• Scenario: You set nLockTime to block 1,000,000 (a future block).

• Case A: All inputs have nSequence = 0xffffffff.

  • Result: The lock is ignored. The transaction can be mined today.

• Case B: At least one input has nSequence < 0xffffffff.

  • Result: The lock is enforced. The transaction is invalid until block 1,000,000.

2. Why does this rule exist?

Satoshi Nakamoto designed this so that a user could "cancel" or "update" a time-locked transaction before it became valid. By submitting a new version of the transaction with a higher sequence number (the original concept for payment channels), the old time-locked version would be superseded.

3. Standard Wallet Policy

Most modern wallets (like Bitcoin Core) set the nSequence to 0xfffffffe (MAX - 1) if they are using nLockTime. This is just low enough to enable the lock while remaining high enough to signal that RBF (Replace-By-Fee) is not being used (unless requested).

4. Logical Flowchart

1. Does every input have nSequence = 0xffffffff?

   • Yes: Ignore nLockTime. Transaction is final.
   • No: Proceed to check nLockTime.

2. Is nLockTime reached (based on current block height/time)?

   • Yes: Transaction is valid.
   • No: Transaction is invalid (rejected by miners).

Input Sequence	nLockTime	Enforced?
0xffffffff	999,999	No
0xfffffffe	999,999	Yes
0x00000000	999,999	Yes

In the next section, we will compare nLockTime with the script-level CLTV.