Rewrote and clarified some sections of the median time-past BIP.

bip-median-past-timelock.mediawiki

@@ -1,6 +1,7 @@
 <pre>
   BIP: XX
-  Title: Median-Past-TimeLock
+  Title: Median time-past as 
+  BIP: XXendpoint for lock-time calculations
   Author: Thomas Kerin <me@thomaskerin.io>
           Mark Friedenbach <mark@friedenbach.org>	
   Status: Draft
@@ -8,111 +9,64 @@
   Created: 2015-08-10
 </pre>
 
+
 ==Abstract==
 
-This BIP is a proposal to redefine the semantics used to determine a time-locked 
+This BIP is a proposal to redefine the semantics used determining a
-transactions eligibilty for inclusion in a block. The proposal is to use a 
+time-locked transactions eligibilty for inclusion in a block. The
-blocks MedianTimePast instead of the included timestamp, ensuring that it 
+median of the last 11 blocks is used instead of the block's timestamp,
-increases monotonically with each block. 
+ensuring that it increases monotonically with each block.
+
 
 ==Motivation==
 
-At present, transactions are excluded from the next block if the present time 
+At present, transactions are excluded from inclusion in a block if the
-or block height is less than that specified in the locktime. Since there is no 
+present time or block height is less than or equal to that specified
-network rule ensuring that block timestamps come in chronological order, 
+in the locktime. Since the consensus rules do not mandate strict
-directly using this can lead to transactions being incorrectly excluded, when 
+ordering of block timestamps, this has the unfortunate outcome of
-they ought to be valid. 
+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 
+This BIP proposes comparing the locktime against the median of the
-last 11 blocks, rather than the time included in the block. The benefit is 
+past 11 block's timestamps, rather than the timestamp of the block
-this figure is derived via consensus, and guaranteed to monotonically advance. 
+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 
+    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];
     }
 
-BIP68 proposes to replace IsFinalTx() and CheckFinalTx() with Locktime(), and CheckLocktime(),
+Lock-time constraints are checked by the consensus method IsFinalTx(),
-allowing a TxIn’s sequence number to specify a relative locktime. 
+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 
+A reference implementation of this proposal is provided in the
-CheckLocktime() to use the next blocks MedianTimePast, should the LOCKTIME_MEDIAN_TIME_PAST 
+following git repository:
-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
 
@@ -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.
-