OP_CHECKSEQUENCEVERIFY ( previously
CHECKSEQUENCEVERIFY (CSV) marks transaction as invalid if the relative lock time of the input (enforced by BIP 68 with nSequence) is not equal to or longer than the value of the top stack item.
The precise semantics are described in BIP 112, soft fork to enforce CSV.
BIP 68 introduces relative lock-time consensus-enforced semantics of the sequence number field to enable a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding outpoint.
BIP 112 allows users to make bitcoins unspendable for a period of time, much like CheckLockTimeVerify (CLTV), but with a relative timelock.
Whereas CLTV locks bitcoins up until a specific, absolute time in the future, CSV locks bitcoins up for a specific amount of time after the CSV transaction is included in a block.
If the sequence number field is filled in, require the output being spent to have a relative minimum height.
e.g a sequence number 200 means there must be at least 200 blocks between the block including the parent transaction and the block includng the child tx.
This allows the creation of revocable outputs bearing increasing sequence number.
Bitcoin transactions currently may specify a locktime indicating when they may be added to a valid block.
Blocks must have a block header time greater than the locktime specified in any transaction in that block.
Miners get to choose what time they use for their header time but no node will accept a block whose time is more than two hours in the future.
This creates a incentive for miners to set their header times to future values in order to include locktimed transactions which weren’t supposed to be included for up to two more hours.
The consensus rules also specify that valid blocks may have a header time greater than that of the median of the 11 previous blocks.
This GetMedianTimePast() time has a key feature we generally associate with time: it can’t go backwards.
BIP 113 specifies a soft fork enforced in the Bitcoin Core 0.12.1 release that weakens this perverse incentive for individual miners to use a future time by requiring that valid blocks have a computed GetMedianTimePast() greater than the locktime specified in any transaction in that block.
Mempool inclusion rules currently require transactions to be valid for immediate inclusion in a block in order to be accepted into the mempool.
The Bitcoin Core 0.12.1 release begins applying the BIP113 rule to received transactions, so transaction whose time is greater than the GetMedianTimePast() will no longer be accepted into the mempool.
Implication for miners: you will begin rejecting transactions that would not be valid under BIP 113, which will prevent you from producing invalid blocks when BIP 113 is enforced on the network.
Any transactions which are valid under the current rules but not yet valid under the BIP 113 rules will either be mined by other miners or delayed until they are valid under BIP 113.
Implication for users: GetMedianTimePast() always trails behind the current time, so a transaction locktime set to the present time will be rejected by nodes running this release until the median time moves forward.
To compensate, subtract one hour from your locktimes to allow those transactions to be included in mempools at approximately the expected time.