Bitcoin full node and query server
Mar 24, 2025
View in context in the libbitcoin Slack #general mirror.
evoskuil22:16
replied to a thread: view
Absolute height locktime ("finality") was implemented in Satoshi's first release ("First commit" in GitHub/bitcoin dated 29 AUG 2009).
class CTransaction
{
public:
...
int nLockTime;
...
bool IsFinal() const
{
if (nLockTime == 0 || nLockTime < nBestHeight)
return true;
foreach(const CTxIn& txin, vin)
if (!txin.IsFinal())
return false;
return true;
}
...
};
class CTxIn
{
public:
...
bool IsFinal() const
{
return (nSequence == UINT_MAX);
}
...
};
This was modified to include absolute timestamp locktime in a commit on 18 OCT 2009 and subsequently released as v0.2.0 on 13 DEC 2009. It also included a change of
nLockTime type to unsigned.
class CTransaction
{
public:
...
unsigned int nLockTime;
...
bool IsFinal(int64 nBlockTime=0) const
{
// 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))
return true;
foreach(const CTxIn& txin, vin)
if (!txin.IsFinal())
return false;
return true;
}
...
};
Block 31,000 was mined on 22 DEC 2009. This is nine days after the tag applied to v0.2.0, and between the tags of v0.2.5 and v0.2.6. So it seems you are referring to enforcement of time-based absolute locktime (block time, as MTP didn't arrive until BIP113) around this approximate block height.
Libbitcoin doesn't implement activation for various forks during this period, as they were just released without activation and themselves applied to all blocks. We do have plans to do so at some point, and have stubbed in several, for historical/educational purposes. To my knowledge bitcoind has also never applied these forks conditionally.
So absolute block locktime was always active, it was forked in v0.2.0 to include time, and that was immediately applied to all blocks. At the time time the integer was also forked from signed to unsigned comparisons (and a validation failure introduced to support it).
// To help v0.1.5 clients who would see it as negative number. please delete this later.
if (nLockTime > INT_MAX)
return error("AcceptTransaction() : not accepting nLockTime beyond 2038");