1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
|
<pre>
BIP: XX
Title: Median-Past-TimeLock
Author: Thomas Kerin <me@thomaskerin.io>
Mark Friedenbach <mark@friedenbach.org>
Status: Draft
Type: Standards Track
Created: 2015-08-10
</pre>
==Abstract==
This BIP is a proposal to redefine the semantics used to determine a time-locked
transactions eligibilty for inclusion in a block. The proposal is to use a
blocks MedianTimePast instead of the included timestamp, ensuring that it
increases monotonically with each block.
==Motivation==
At present, transactions are excluded from the next block if the present time
or block height is less than that specified in the locktime. Since there is no
network rule ensuring that block timestamps come in chronological order,
directly using this can lead to transactions being incorrectly excluded, when
they ought to be valid.
This BIP proposes comparing the locktime against the MedianTimePast over the
last 11 blocks, rather than the time included in the block. The benefit is
this figure is derived via consensus, and guaranteed to monotonically advance.
This proposal seeks to ensure reliable behaviour in locktime calculations as
required by BIP65, BIPXX (OP_CHECKSEQUENCEVERIFY), and BIP68.
==Specification==
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
blocks time.
enum { nMedianTimeSpan=11 };
int64_t GetMedianTimePast() const
{
int64_t pmedian[nMedianTimeSpan];
int64_t* pbegin = &pmedian[nMedianTimeSpan];
int64_t* pend = &pmedian[nMedianTimeSpan];
const CBlockIndex* pindex = this;
for (int i = 0; i < nMedianTimeSpan && pindex; i++, pindex = pindex->pprev)
*(--pbegin) = pindex->GetBlockTime();
std::sort(pbegin, pend);
return pbegin[(pend - pbegin)/2];
}
BIP68 proposes to replace IsFinalTx() and CheckFinalTx() with Locktime(), and CheckLocktime(),
allowing a TxIn’s sequence number to specify a relative locktime.
Adopting the use of MedianTimePast in comparisons with a locktime, involves modifying
CheckLocktime() to use the next blocks MedianTimePast, should the LOCKTIME_MEDIAN_TIME_PAST
flag be set.
The following function introduces this behaviour:
int64_t CheckLockTime(const CTransaction &tx, int flags)
{
AssertLockHeld(cs_main);
// By convention a negative value for flags indicates that the
// current network-enforced consensus rules should be used. In
// a future soft-fork scenario that would mean an
// IsSuperMajority check against chainActive.Tip().
if (flags < 0)
flags = LOCKTIME_MEDIAN_TIME_PAST;
// pcoinsTip contains the UTXO set for chainActive.Tip()
const CCoinsView *pCoinsView = pcoinsTip;
// CheckLockTime() uses chainActive.Height()+1 to evaluate
// nLockTime because when LockTime() is called within
// CBlock::AcceptBlock(), the height of the block *being*
// evaluated is what is used. Thus if we want to know if a
// transaction can be part of the *next* block, we need to call
// LockTime() with one more than chainActive.Height().
const int nBlockHeight = chainActive.Height() + 1;
// Timestamps on the other hand don't get any special treatment,
// because we can't know what timestamp the next block will have,
// and there aren't timestamp applications where it matters.
int64_t nBlockTime = GetAdjustedTime();
if (flags & LOCKTIME_MEDIAN_TIME_PAST)
nBlockTime -= ((CBlockIndex::nMedianTimeSpan + 1) >> 1) * Params().GetConsensus().nPowTargetSpacing;
return LockTime(tx, flags, pCoinsView, nBlockHeight, nBlockTime);
}
Where a value for LocktimeCutoff is used, the switchover logic is implemented as such:
int64_t nLockTimeCutoff = (nLockTimeFlags & LOCKTIME_MEDIAN_TIME_PAST)
? nMedianTimePast
: pblock->GetBlockTime();
==Upgrade and Testing Plan==
TBD
==Acknowledgements==
Mark Friedenbach for designing and authoring the actual implementation for Median-
Past time-lock.
==Implementations==
A reference implementation is provided in the following git repository:
https://github.com/maaku/bitcoin/tree/medianpasttimelock
==Deployment==
We reuse the double-threshold switchover mechanism from BIPs 34 and 66, with the
same thresholds, but for block.nVersion = 4. The new rules are in effect for
every block (at height H) with nVersion = 4 and at least 750 out of 1000 blocks
preceding it (with heights H-1000...H-1) also have nVersion = 4. Furthermore,
when 950 out of the 1000 blocks preceding a block do have nVersion = 4,
nVersion = 3 blocks become invalid, and all further blocks enforce the new rules.
It is recommended that this soft-fork deployment trigger include other related
proposals for improving Bitcoin's lock-time capabilities, such as BIP 65, BIP68
and OP_CHECKSEQUENCEVERIFY.
==Compatibility==
This BIP is not known to introduce any compatibility concerns.
==References==
[https://github.com/bitcoin/bips/blob/master/bip-00.mediawiki BIP65: OP_CHECKLOCKTIMEVERIFY]
[https://github.com/bitcoin/bips/blob/master/bip-00.mediawiki BIP68: Consensus-enforced transaction replacement signaled via sequence numbers]
[https://github.com/bitcoin/bips/blob/master/bip-00.mediawiki BIP65: OP_CHECKSEQUENCEVERIFY]
==Copyright==
This document is placed in the public domain.
|
