At present, transactions are excluded from inclusion in a block if the present time or block height is less than or equal to that specified in the locktime.
Since the consensus rules do not mandate strict ordering of block timestamps, this has the unfortunate outcome of creating a perverse incentive for miners to lie about the time of their blocks in order to collect more fees by including transactions that by wall clock determination have not yet matured.
This BIP proposes comparing the locktime against the median of the past 11 block's timestamps, rather than the timestamp of the block including the transaction.
Existing consensus rules guarantee this value to monotonically advance, thereby removing the capability for miners to claim more transaction fees by lying about the timestamps of their block.
This proposal seeks to ensure reliable behaviour in locktime calculations as required by BIP65 (`CHECKLOCKTIMEVERIFY`) and matching the behavior of BIP68 (sequence numbers) and BIP112 (`CHECKSEQUENCEVERIFY`).
The values for transaction locktime remain unchanged.
The difference is only in the calculation determining whether a transaction can be included.
Instead of an unreliable timestamp, the following function is used to determine the current block time for the purpose of checking lock-time constraints:
This BIP is to be deployed by "versionbits" BIP9 using bit 0.
For Bitcoin '''mainnet''', the BIP9 '''starttime''' will be midnight 1st May 2016 UTC (Epoch timestamp 1462060800) and BIP9 '''timeout''' will be midnight 1st May 2017 UTC (Epoch timestamp 1493596800).
For Bitcoin '''testnet''', the BIP9 '''starttime''' will be midnight 1st March 2016 UTC (Epoch timestamp 1456790400) and BIP9 '''timeout''' will be midnight 1st May 2017 UTC (Epoch timestamp 1493596800).
