nLockTime vs. CheckLockTimeVerify (CLTV)

Bitcoin has two ways to enforce absolute timelocks: nLockTime (the transaction-level field) and CheckLockTimeVerify (the script-level opcode). While they serve similar goals, they operate at different stages of the protocol.

1. nLockTime (Transaction-Level)

• Mechanism: A field in the transaction itself.

• Location: The last 4 bytes of the raw hex.

• Constraint: It prevents the entire transaction from being included in a block until the time is reached.

• Flexibility: The sender can choose to set or remove the lock when creating the transaction.

2. CLTV (Script-Level / BIP 65)

• Mechanism: An opcode (OP_CHECKLOCKTIMEVERIFY) used inside a ScriptPubKey.

• Location: Inside the UTXO "Lock."

• Constraint: It makes a specific output unspendable until a certain time.

• Flexibility: The lock is "hard-coded" into the coins. The owner cannot remove it, even if they have the private key.

3. How They Work Together

CLTV actually works by inspecting the nLockTime field. When a node runs a script containing CLTV, it checks:

1. Is the value in the nLockTime field greater than or equal to the value specified in the script?

2. Is the nSequence field set to enforce the lock (less than 0xffffffff)?

If these conditions are not met, the script fails, and the transaction is invalid. Essentially, CLTV forces a transaction to use a specific nLockTime.

4. Summary Table

Feature	nLockTime	CLTV (BIP 65)
Control	Sender-controlled	Enforced by the coin's lock
Visibility	Public in the TX hex	Hidden in the script (until spent)
Use Case	Post-dating a payment	Trustless escrow / Hashed Timelock Contracts (HTLCs)
Level	Transaction Data	Consensus Script

In the final section, we will build a Python Locktime Decoder.