130 / 691CSV

CHECKSEQUENCEVERIFY

CSV enforces a relative lock for a particular input. The delay relates to confirmation of the spent output, not wallet creation or transaction signing.

Under BIP 112, OP_CHECKSEQUENCEVERIFY checks a script argument against the input's nSequence. BIP 68 then enforces the output's corresponding age; these are linked checks, not automatic payment delivery.

CSV constrains the nSequence of the input being spent. It does not itself measure UTXO age; BIP 68 transaction validation uses confirmation history to prevent inclusion too early. [BIP 112 — OP_CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time]

For an ordinary argument without the disable flag, CSV requires transaction version at least 2 and nSequence bit 31 clear. A negative argument or incompatible sequence causes failure. [BIP 112 — OP_CHECKSEQUENCEVERIFY] [Bitcoin Core v29.0 — Script interpreter]

Bit 22 distinguishes blocks from time. When set, one unit equals 512 seconds, so time is encoded in 512-second steps. Argument and nSequence types must match. [BIP 68 — Relative lock-time]

The low 16 bits encode the delay, using mask 0x0000ffff. CSV compares this encoded range together with its type; it does not compare the ordering of whole unmasked nSequence numbers. [BIP 68 — Relative lock-time] [Bitcoin Core v29.0 — Script interpreter]

If an output confirms at H = 900000 and the block delay is 10, the earliest candidate height is H + 10 = 900010. Nine blocks are insufficient; a block count does not guarantee exact minutes. [BIP 68 — Relative lock-time] [Bitcoin Core v29.0 — Transaction sequence locks]

The time origin is Median Time Past of the block before output confirmation. It is compared with MTP before the candidate block; code 2 means at least 1024 seconds between those medians, not two local clocks. [BIP 68 — Relative lock-time] [Bitcoin Core v29.0 — Transaction sequence locks]

A zero delay adds no waiting, but ordinary CSV still applies its other checks. If a nonnegative argument itself sets bit 31, CSV behaves as a NOP; that argument does not impose a relative time lock. [BIP 112 — OP_CHECKSEQUENCEVERIFY] [Bitcoin Core v29.0 — Script interpreter]

Each input has its own confirmation and sequence; all applicable transaction locks must be satisfied. Reorganization can move the starting confirmation, so earlier eligibility is not irreversible. [BIP 68 — Relative lock-time] [Bitcoin Core v29.0 — Transaction sequence locks]

CSV leaves its argument on the stack, often followed by OP_DROP. Signature conditions and other branches determine authorization; a time limit neither restores a lost key nor rules out an earlier alternative path. [BIP 112 — OP_CHECKSEQUENCEVERIFY] [Bitcoin Developer Reference — Transactions]

BIP 112 introduced CSV by replacing OP_NOP3 alongside BIP 68/113 rules. After the delay, the transaction still needs delivery and confirmation; fees, data availability and chain state still matter. [BIP 112 — OP_CHECKSEQUENCEVERIFY] [Bitcoin Core 0.12.1 — BIP 68/112/113 release notes]

For the clearest picture, read this entry together with CHECKLOCKTIMEVERIFY, Bitcoin Script opcode, Timelock, Bitcoin Script. The reverse links also lead from Confirmation, Timelock, Bitcoin Script opcode, CHECKLOCKTIMEVERIFY.

DOC · 001BIP 112 — OP_CHECKSEQUENCEVERIFYSpecificationDOC · 002BIP 68 — Relative lock-timeSpecificationDOC · 003Bitcoin Core v29.0 — Script interpreterDocumentationDOC · 004Bitcoin Core v29.0 — Transaction sequence locksDocumentationDOC · 005Bitcoin Developer Reference — TransactionsDocumentationDOC · 006Bitcoin Core 0.12.1 — BIP 68/112/113 release notesDocumentation
Source-first · No investment advice