BIP: 113 Title: Median time-past as endpoint for lock-time calculations Author: Thomas Kerin <[email protected]> Mark Friedenbach <[email protected]> Status: Draft Type: Standards Track Created: 2015-08-10
This BIP is a proposal to redefine the semantics used in determining a time-locked transaction's eligibility for inclusion in a block. The median of the last 11 blocks is used instead of the block's timestamp, ensuring that it increases monotonically with each block.
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), 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:
int64_t GetMedianTimePast(const CBlockIndex* pindex)
{
int64_t pmedian[nMedianTimeSpan];
int64_t* pbegin = &pmedian[nMedianTimeSpan];
int64_t* pend = &pmedian[nMedianTimeSpan];
for (int i = 0; i < nMedianTimeSpan && pindex; i++, pindex = pindex->pprev)
*(--pbegin) = pindex->GetBlockTime();
std::sort(pbegin, pend);
return pbegin[(pend - pbegin)/2];
}
Lock-time constraints are checked by the consensus method IsFinalTx(), or LockTime() under BIP68. These methods take the block time as one parameter. This BIP proposes that after activation calls to IsFinalTx() or LockTime() within consensus code use the return value of `GetMedianTimePast(pindexPrev)` instead.
A reference implementation of this proposal is provided by the following pull request:
We reuse the double-threshold switchover mechanism from BIPs 34 and 66, with the same thresholds, but for nVersion = 8. The new rules are in effect for every block (at height H) with nVersion = 8 and at least 750 out of 1000 blocks preceding it (with heights H-1000..H-1) also have nVersion = 8. Furthermore, when 950 out of the 1000 blocks preceding a block do have nVersion = 8, nVersion = 3 blocks become invalid, and all further blocks enforce the new rules.
When assessing the block version as mask of ~0x20000007 must be applied to work around the complications caused by BIP101's premature use of the undecided version bits proposal.
By applying ~0x20000007 with nVersion = 8, the thresholds should be tested comparing block nVersion >= 4 as this will save a bit for future use.
It is recommended that this soft-fork deployment trigger include other related proposals for improving Bitcoin's lock-time capabilities, including:
BIP 65: CHECKLOCKTIMEVERIFY,
BIP 68: Consensus-enforced transaction replacement signalled via sequence numbers,
and BIP 112: CHECKSEQUENCEVERIFY.
Mark Friedenbach for designing and authoring the reference implementation of this BIP.
Thanks go to Gregory Maxwell who came up with the original idea, in #bitcoin-wizards on 2013-07-16.
Thomas Kerin authored this BIP document.
Transactions generated using time-based lock-time will take approximately an hour longer to confirm than would be expected under the old rules. This is not known to introduce any compatibility concerns with existing protocols.
BIP68: Consensus-enforced transaction replacement signaled via sequence numbers
Softfork deployment considerations
This document is placed in the public domain.