Update with BIP assignments

Update deployment methodology

1 files changed, 137 insertions, 0 deletions

diff --git a/bip-0113.mediawiki b/bip-0113.mediawiki
new file mode 100644
index 0000000..b7313e3
--- /dev/null
+++ b/bip-0113.mediawiki
@@ -0,0 +1,137 @@
+<pre>
+  BIP: 113
+  Title: Median time-past as endpoint for lock-time calculations
+  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 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.
+
+
+==Motivation==
+
+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, and BIP112 (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 
+block time for the purpose of checking lock-time constraints:
+
+    enum { nMedianTimeSpan=11 };
+    
+    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 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 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, 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==
+
+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.
+
+
+==Compatibility==
+
+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-0065.mediawiki BIP65: OP_CHECKLOCKTIMEVERIFY]
+
+[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-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==
+
+This document is placed in the public domain.