From 4e06ec12b46b81e6169b1818950cbdf71fc5e0c4 Mon Sep 17 00:00:00 2001 From: Thomas Kerin Date: Wed, 12 Aug 2015 00:06:41 +0100 Subject: [PATCH 1/6] Initial commit of BIP: Median-past Timelock --- bip-median-past-timelock.mediawiki | 146 +++++++++++++++++++++++++++++ 1 file changed, 146 insertions(+) create mode 100644 bip-median-past-timelock.mediawiki diff --git a/bip-median-past-timelock.mediawiki b/bip-median-past-timelock.mediawiki new file mode 100644 index 00000000..51ebe73e --- /dev/null +++ b/bip-median-past-timelock.mediawiki @@ -0,0 +1,146 @@ +
+  BIP: XX
+  Title: Median-Past-TimeLock
+  Author: Thomas Kerin 
+          Mark Friedenbach 	
+  Status: Draft
+  Type: Standards Track
+  Created: 2015-08-10
+
+ +==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 [1], OP_CHECKSEQUENCEVERIFY [2], and BIP68 [3]. + +==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== + + + +==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. + From 80b57fe0c65e7371e5e60baf7ae2d4fac38b04b8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E0=B8=BFtcDrak?= Date: Wed, 12 Aug 2015 19:13:23 +0100 Subject: [PATCH 2/6] Added note about compatibility and formatting --- bip-median-past-timelock.mediawiki | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/bip-median-past-timelock.mediawiki b/bip-median-past-timelock.mediawiki index 51ebe73e..2e4340f9 100644 --- a/bip-median-past-timelock.mediawiki +++ b/bip-median-past-timelock.mediawiki @@ -28,7 +28,7 @@ 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 [1], OP_CHECKSEQUENCEVERIFY [2], and BIP68 [3]. +required by BIP65, BIPXX (OP_CHECKSEQUENCEVERIFY), and BIP68. ==Specification== @@ -133,11 +133,13 @@ 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== From d1d4af9b135b22f45d0338c6f37007710c00056b Mon Sep 17 00:00:00 2001 From: Mark Friedenbach Date: Mon, 17 Aug 2015 16:30:16 -0700 Subject: [PATCH 3/6] Rewrote and clarified some sections of the median time-past BIP. --- bip-median-past-timelock.mediawiki | 148 +++++++++++------------------ 1 file changed, 57 insertions(+), 91 deletions(-) diff --git a/bip-median-past-timelock.mediawiki b/bip-median-past-timelock.mediawiki index 2e4340f9..4bfeffa4 100644 --- a/bip-median-past-timelock.mediawiki +++ b/bip-median-past-timelock.mediawiki @@ -1,6 +1,7 @@ 
   BIP: XX
-  Title: Median-Past-TimeLock
+  Title: Median time-past as 
+  BIP: XXendpoint for lock-time calculations
   Author: Thomas Kerin 
           Mark Friedenbach 	
   Status: Draft
@@ -8,111 +9,64 @@
   Created: 2015-08-10
+ ==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. +This BIP is a proposal to redefine the semantics used determining a +time-locked transactions eligibilty 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. + ==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. +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 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 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, BIPXX (OP_CHECKSEQUENCEVERIFY), and BIP68. +required by BIP65, BIP68, and BIPXX (OP_CHECKSEQUENCEVERIFY). + ==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. +block time for the purpose of checking lock-time constraints: - - enum { nMedianTimeSpan=11 }; - - int64_t GetMedianTimePast() const + enum { nMedianTimeSpan=11 }; + + int64_t GetMedianTimePast(const CBlockIndex* pindex) { - 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]; + 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]; } -BIP68 proposes to replace IsFinalTx() and CheckFinalTx() with Locktime(), and CheckLocktime(), -allowing a TxIn’s sequence number to specify a relative locktime. +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. -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: +A reference implementation of this proposal is provided in the +following git repository: https://github.com/maaku/bitcoin/tree/medianpasttimelock @@ -128,21 +82,33 @@ 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. +and CHECKSEQUENCEVERIFY. + + +==Acknowledgements== + +Mark Friedenbach for designing and authoring the reference +implementation of this BIP. + +Thomas Kerin authored ths BIP document. ==Compatibility== -This BIP is not known to introduce any compatibility concerns. +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. + ==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] +[https://github.com/bitcoin/bips/blob/master/bip-00.mediawiki BIPXX: CHECKSEQUENCEVERIFY] + ==Copyright== This document is placed in the public domain. - From 2f5b94a3d9c54b268b42171f099100d8816a67e9 Mon Sep 17 00:00:00 2001 From: Thomas Kerin Date: Tue, 18 Aug 2015 01:54:55 +0100 Subject: [PATCH 4/6] Update references --- bip-median-past-timelock.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-median-past-timelock.mediawiki b/bip-median-past-timelock.mediawiki index 4bfeffa4..26ab7fae 100644 --- a/bip-median-past-timelock.mediawiki +++ b/bip-median-past-timelock.mediawiki @@ -102,9 +102,9 @@ concerns with existing protocols. ==References== -[https://github.com/bitcoin/bips/blob/master/bip-00.mediawiki BIP65: OP_CHECKLOCKTIMEVERIFY] +[https://github.com/bitcoin/bips/blob/master/bip-0065.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-0068.mediawiki BIP68: Consensus-enforced transaction replacement signaled via sequence numbers] [https://github.com/bitcoin/bips/blob/master/bip-00.mediawiki BIPXX: CHECKSEQUENCEVERIFY] From aa4056a44224f38472f5a0eecf13797ef9e633cc Mon Sep 17 00:00:00 2001 From: Mark Friedenbach Date: Mon, 17 Aug 2015 17:55:04 -0700 Subject: [PATCH 5/6] Fix typos. --- bip-median-past-timelock.mediawiki | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/bip-median-past-timelock.mediawiki b/bip-median-past-timelock.mediawiki index 26ab7fae..3d3e7db0 100644 --- a/bip-median-past-timelock.mediawiki +++ b/bip-median-past-timelock.mediawiki @@ -1,7 +1,6 @@ 
   BIP: XX
-  Title: Median time-past as 
-  BIP: XXendpoint for lock-time calculations
+  Title: Median time-past as endpoint for lock-time calculations
   Author: Thomas Kerin 
           Mark Friedenbach 	
   Status: Draft
@@ -12,8 +11,8 @@
 
 ==Abstract==
 
-This BIP is a proposal to redefine the semantics used determining a
-time-locked transactions eligibilty for inclusion in a block. The
+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.
 
@@ -90,7 +89,7 @@ and CHECKSEQUENCEVERIFY.
 Mark Friedenbach for designing and authoring the reference
 implementation of this BIP.
 
-Thomas Kerin authored ths BIP document.
+Thomas Kerin authored this BIP document.
 
 
 ==Compatibility==

From d4c9a236ecb947866c61aefb868b284498489c2b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E0=B8=BFtcDrak?= 
Date: Mon, 24 Aug 2015 19:06:13 +0100
Subject: [PATCH 6/6] Update with BIP assignments

Update deployment methodology
---
 ...t-timelock.mediawiki => bip-0113.mediawiki | 46 ++++++++++++++-----
 1 file changed, 35 insertions(+), 11 deletions(-)
 rename bip-median-past-timelock.mediawiki => bip-0113.mediawiki (67%)

diff --git a/bip-median-past-timelock.mediawiki b/bip-0113.mediawiki
similarity index 67%
rename from bip-median-past-timelock.mediawiki
rename to bip-0113.mediawiki
index 3d3e7db0..b7313e30 100644
--- a/bip-median-past-timelock.mediawiki
+++ b/bip-0113.mediawiki
@@ -1,5 +1,5 @@
 
-  BIP: XX
+  BIP: 113
   Title: Median time-past as endpoint for lock-time calculations
   Author: Thomas Kerin 
           Mark Friedenbach 	
@@ -35,7 +35,7 @@ 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, BIP68, and BIPXX (OP_CHECKSEQUENCEVERIFY).
+required by BIP65 (CHECKLOCKTIMEVERIFY), BIP68, and BIP112 (CHECKSEQUENCEVERIFY).
 
 
 ==Specification==
@@ -72,16 +72,33 @@ 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.
+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
+[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010396.html BIP101's premature use]
+of the [https://gist.github.com/sipa/bf69659f43e763540550 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, such as BIP 65, BIP68
-and CHECKSEQUENCEVERIFY.
+proposals for improving Bitcoin's lock-time capabilities, including:
+
+[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65]: 
+CHECKLOCKTIMEVERIFY, 
+
+[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 68]: 
+Consensus-enforced transaction replacement signalled via sequence numbers,
+
+and [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP 112]: 
+CHECKSEQUENCEVERIFY.
 
 
 ==Acknowledgements==
@@ -89,6 +106,9 @@ and 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.
 
 
@@ -105,7 +125,11 @@ concerns with existing protocols.
 
 [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Consensus-enforced transaction replacement signaled via sequence numbers]
 
-[https://github.com/bitcoin/bips/blob/master/bip-00.mediawiki BIPXX: CHECKSEQUENCEVERIFY]
+[https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP112: CHECKSEQUENCEVERIFY]
+
+[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010396.html Softfork deployment considerations]
+
+[https://gist.github.com/sipa/bf69659f43e763540550 Version bits]
 
 
 ==Copyright==