Remove BIP68's dependence on this BIP. Remove deployment details.

1 files changed, 10 insertions, 33 deletions

diff --git a/bip-0113.mediawiki b/bip-0113.mediawiki
index 15fa4f3..d21054b 100644
--- a/bip-0113.mediawiki
+++ b/bip-0113.mediawiki
@@ -34,8 +34,9 @@ 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).
+This proposal seeks to ensure reliable behaviour in locktime calculations
+as required by BIP65 (CHECKLOCKTIMEVERIFY) and matching the behavior of
+BIP68 (sequence numbers) and BIP112 (CHECKSEQUENCEVERIFY).
 
 
 ==Specification==
@@ -58,11 +59,10 @@ block time for the purpose of checking lock-time constraints:
         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.
+Lock-time constraints are checked by the consensus method IsFinalTx().
+This method takes the block time as one parameter. This BIP proposes
+that after activation calls to IsFinalTx() within consensus code use
+the return value of `GetMedianTimePast(pindexPrev)` instead.
 
 A reference implementation of this proposal is provided by the
 following pull request:
@@ -72,33 +72,10 @@ https://github.com/bitcoin/bitcoin/pull/6566
 
 ==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.
+This BIP is to be deployed by either version-bits BIP9 or by isSuperMajority().
+Exact details TBD.
 
-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.
+It is recommended to deploy BIP68 and BIP112 at the same time as this BIP.
 
 
 ==Acknowledgements==