mirrors/bitcoin-bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-03-01 09:59:47 +01:00
Code Issues Projects Releases Wiki Activity

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

Browse source
This commit is contained in:
Alex Morcos 2016-02-29 15:59:43 -05:00
parent 7a9cdfe919
commit 8d7748e6fb
1 changed files with 10 additions and 33 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

43
bip-0113.mediawiki
View file

@ -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==