The Wiki was incorrect (I wrote the original text and I apologize). As indicated in the question, the ordering on the Wiki was backwards. However, upon investigating, I don't believe it was a hard fork. In the original Bitcoin 0.1 code, we find the following function:
bool IsFinal() const
if (nLockTime == 0 || nLockTime < nBestHeight)
This function is called in the mining code that selects which transactions to mine:
if (tx.IsCoinBase() || !tx.IsFinal())
That means no node running the default Bitcoin 0.1 code would mine a transaction unless its nLockTime was less than the next block's height. However, I don't see any code in 0.1 that rejects blocks with a "non-final" transaction, so this isn't a consensus rule.
Months later, in code that became part of Bitcoin 0.1.6, the timelock feature is added:
- bool IsFinal() const
+ bool IsFinal(int64 nBlockTime=0) const
- if (nLockTime == 0 || nLockTime < nBestHeight)
+ // Time based nLockTime implemented in 0.1.6,
+ // do not use time based until most 0.1.5 nodes have upgraded.
+ if (nBlockTime == 0)
+ nBlockTime = GetAdjustedTime();
+ if (nLockTime == 0)
+ return true;
+ if (nLockTime < (nLockTime < 500000000 ? nBestHeight : nBlockTime))
And the same commit also adds consensus enforcement for both heightlocks and timelocks:
+ // Check that all transactions are finalized (starting around 30 Nov 2009)
+ if (nBestHeight > 31000) // 25620 + 5320
+ foreach(const CTransaction& tx, vtx)
+ if (!tx.IsFinal(nTime))
+ return error("AcceptBlock() : contains a non-final transaction");
In short, in version 0.1.0 had no consensus rules about the nLockTime field and version 0.1.6 added a consensus rule that included both heightlocks and timelocks. That's making the rules more strict and so I believe it was a soft fork which activated at block 31,000.
Perhaps of interest, this is the earliest soft fork of which I'm aware (as of this writing, it's earlier than any entries at the time of writing on the Wiki's consensus versions list or BitMex's consensus forks list). Despite being so early, the fork was obviously made with care, giving the network about a month to upgrade and preparing for potential problems ahead of time.