From 8d7748e6fb044d6055d3448b2028212677d1d90b Mon Sep 17 00:00:00 2001 From: Alex Morcos Date: Mon, 29 Feb 2016 15:59:43 -0500 Subject: Remove BIP68's dependence on this BIP. Remove deployment details. --- bip-0113.mediawiki | 43 ++++++++++--------------------------------- 1 file changed, 10 insertions(+), 33 deletions(-) (limited to 'bip-0113.mediawiki') 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== -- cgit v1.2.3