Merge pull request #260 from btcdrak/bip68mtp

BIP68: update specification to assume MTP

1 files changed, 5 insertions, 3 deletions

diff --git a/bip-0068.mediawiki b/bip-0068.mediawiki
index 02bc2a4..55905af 100644
--- a/bip-0068.mediawiki
+++ b/bip-0068.mediawiki
@@ -24,13 +24,15 @@ The transaction nLockTime is used to prevent the mining of a transaction until a
 
 This specification defines the meaning of sequence numbers for transactions with an nVersion greater than or equal to 2 for which the rest of this specification relies on.
 
+All references to median-time-past (MTP) are as defined by BIP113.
+
 If bit (1 << 31) of the sequence number is set, then no consensus meaning is applied to the sequence number and can be included in any block under all currently possible circumstances.
 
 If bit (1 << 31) of the sequence number is not set, then the sequence number is interpreted as an encoded relative lock-time.
 
 The sequence number encoding is interpreted as follows: 
 
-Bit (1 << 22) determines if the relative lock-time is time-based or block based: If the bit is set, the relative lock-time specifies a timespan in units of 512 seconds granularity. The timespan starts from the median-time-past (MTP) of the output’s previous block, and ends either at the MTP of the previous block or at the nTime of the transaction’s block (depending on the enforcement status of BIP113). If the bit is not set, the relative lock-time specifies a number of blocks.
+Bit (1 << 22) determines if the relative lock-time is time-based or block based: If the bit is set, the relative lock-time specifies a timespan in units of 512 seconds granularity. The timespan starts from the median-time-past of the output’s previous block, and ends at the MTP of the previous block. If the bit is not set, the relative lock-time specifies a number of blocks.
 
 The flag (1<<22) is the highest order bit in a 3-byte signed integer for use in bitcoin scripts as a 3-byte PUSHDATA with OP_CHECKSEQUENCEVERIFY (BIP 112).
 
@@ -43,7 +45,7 @@ For time based relative lock-time, 512 second granularity was chosen because bit
 When the relative lock-time is time-based, it is interpreted as a minimum block-time constraint over the input's age. A relative time-based lock-time of zero indicates an input which can be included in any block. More generally, a relative time-based lock-time n can be included into any block produced 512 * n seconds after the mining date of the output it is spending, or any block thereafter.
 The mining date of the output is equals to the median-time-past of the previous block which mined it.
 
-The block produced time is either equals to median time past of its parent or to its nTime field, depending on the state of BIP113 median-time-past.
+The block produced time is equal to the median-time-past of its previous block.
 
 When the relative lock-time is block-based, it is interpreted as a minimum block-height constraint over the input's age. A relative block-based lock-time of zero indicates an input which can be included in any block. More generally, a relative block lock-time n can be included n blocks after the mining date of the output it is spending, or any block thereafter.
 
@@ -191,7 +193,7 @@ This BIP was edited by BtcDrak, Nicolas Dorier and kinoshitajona.
 
 This BIP is to be deployed by either version-bits BIP9 or by isSuperMajority(). Exact details TDB.
 
-It is recommended to deploy BIP112 and BIP113 at the same time as this BIP.
+BIP68 MUST be deployed together with BIP113. It is also recommended to deploy BIP112 at the same time.
 
 ==Compatibility==