CSV is short for OP_CHECKSEQUENCEVERIFY in Bitcoin Script. Together with BIP 68, it enables a relative lock: a particular spending path becomes usable only when the confirmed output is old enough. An output is a received amount with spending conditions. Waiting alone neither replaces a signature nor sends money.
Anna and Peter can spend their jointly held coins by agreement. They also want a recovery path Anna can use alone, but only after a delay measured from confirmation of the relevant output. CSV helps enforce this condition. Unlike CLTV, which targets a fixed height or time, its boundary is not one predetermined point in the whole history. It depends on particular coins. Creating a wallet, preparing a signature or leaving an unconfirmed transaction waiting does not replace that starting point. A wallet is an application or device for receiving and sending bitcoin. [1] [2] [8]
A block groups transactions into a batch added to the shared history. Block height is a block’s position in the chain. Imagine an output confirmed at height 900000 and a required block delay of 10. Under this lock, the earliest spending block is 900010. An interval of just 9 blocks is too short. This does not promise an exact number of minutes: blocks do not arrive at regular intervals. Nor is sufficient age a payment confirmation. The transaction must otherwise be valid, and a miner must actually include it in a block. [2] [4] [9]
A delay can also be encoded in steps of 512 seconds. Code 2 then represents 1024 seconds. But the comparison is not between two computer clocks. The starting point is Median Time Past of the block before the one that confirmed the output; the other endpoint is Median Time Past of the block before the candidate block. This is the middle timestamp among the last up to 11 blocks after sorting. The difference between these medians must reach the required delay. It is not a precise local-time alarm. [2] [4] [7]
A wallet may combine several previously received amounts for a payment. Each transaction input refers to a previously received output, whose age is measured from its confirmation in the chain. The input itself contains the nSequence field. That field carries the information used for relative waiting. It is not enough for only some of the money to be old enough: all applicable transaction locks must be satisfied. A chain reorganisation can also change where confirmation occurred. Earlier eligibility to spend is therefore not an irreversible property of a coin. In a reorganisation, the network adopts another valid branch of the chain, replacing part of its previous block history. [2] [4] [9]
A Full Node independently verifies the rules through linked checks. CSV under BIP 112 compares the script argument with nSequence of the input that spends the output. It does not itself calculate age; BIP 68 handles that during transaction validation. For an ordinary argument without the disable flag, transaction version must be at least 2 and nSequence bit 31 must be clear. A bit is a small switch inside a numeric field. A negative argument, an older version or incompatible nSequence makes the check fail. [1] [2] [3]
Bit 22 determines how to read the delay. If clear, the unit is blocks; if set, the unit is a step of 512 seconds. The script argument and nSequence must use the same kind. Think of comparing measurements: a larger number is not enough if one side counts kilometres and the other hours. Here, the mismatch is between a block count and a time interval. [1] [2] [3]
The low 16 bits carry the delay length. Mask 0x0000ffff selects that part of the numeric field. CSV compares this part together with the delay type; it does not treat any large nSequence as automatically meaning a longer wait. After the relevant bits are selected, the script requirement must not exceed the input value. This is an important technical boundary for wallet designers, but ordinary users should not configure it by hand without understanding the whole procedure. [1] [2] [3]
A zero delay adds no waiting, but the other checks of ordinary CSV still apply. A different case arises when the nonnegative script argument itself has bit 31 set. CSV then behaves as a NOP, an instruction with no effect on the relative lock. Such an argument does not enforce waiting. This must be distinguished from the same flag in the input’s nSequence: with an ordinary argument, that input flag must be clear. [1] [3]
If Anna’s recovery path needs her signature, she must provide it after the delay too. A private key is a secret numerical value used to create such a signature. A lost private key does not return, and another branch may still allow earlier spending. During script execution CSV leaves its argument on the stack, a working pile of data; OP_DROP often follows to remove it. Removing that data does not authorize anyone to take the money. Signatures and the other conditions of the chosen path determine that. [1] [3] [5]
BIP 112 introduced CSV by replacing OP_NOP3 alongside BIP 68 and BIP 113. It is an active capability, not merely a plan. Uses include Lightning Network payment channels, where a delay can give the other party time to respond; it does not arrange that response. Once the wait is over, the transaction still needs delivery and confirmation. Fees, available data and the chain state matter. Bitcoin Core v29.0 and the listed specifications document the validation details. [1] [2] [6]
For the clearest picture, read this entry together with CLTV, Opcode, Timelock, Bitcoin Script, Bitcoin, Full Node. The reverse links also lead from Confirmation, Timelock, HTLC, Opcode.