依据 BIP 112，OP_CHECKSEQUENCEVERIFY 对照输入的 nSequence 检查脚本参数。BIP 68 随后强制相应输出年龄；这是关联的两项检查，不是自动付款。
CSV 约束被花费输入的 nSequence。它本身不测量 UTXO 年龄；BIP 68 交易验证利用确认历史防止过早纳入区块。 [BIP 112 — OP_CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time]
对于没有禁用标志的普通参数，CSV 要求交易版本至少为 2，且 nSequence 第 31 位清零。负参数或不兼容 sequence 会导致失败。 [BIP 112 — OP_CHECKSEQUENCEVERIFY] [Bitcoin Core v29.0 — Script interpreter]
第 22 位区分区块与时间。置位时单位为 512 秒，因此按 512 秒步长编码时间。参数与 nSequence 类型必须一致。 [BIP 68 — Relative lock-time]
低 16 位编码延迟，掩码为 0x0000ffff。CSV 比较该编码范围及类型，而不是直接比较未掩码的整个 nSequence 数值。 [BIP 68 — Relative lock-time] [Bitcoin Core v29.0 — Script interpreter]
若输出在 H = 900000 确认，区块延迟为 10，最早候选高度为 H + 10 = 900010。九个区块不够；区块数量不保证精确分钟数。 [BIP 68 — Relative lock-time] [Bitcoin Core v29.0 — Transaction sequence locks]
时间起点是输出确认前一区块的 Median Time Past。将其与候选区块前一区块的 MTP 比较；代码 2 表示两中位数至少相差 1024 秒，而不是两个本地时钟。 [BIP 68 — Relative lock-time] [Bitcoin Core v29.0 — Transaction sequence locks]
零延迟不增加等待，但普通 CSV 仍执行其他检查。如果非负参数自身设置第 31 位，CSV 按 NOP 行事；该参数不会施加相对时间锁。 [BIP 112 — OP_CHECKSEQUENCEVERIFY] [Bitcoin Core v29.0 — Script interpreter]
每个输入都有自己的确认和 sequence，交易的全部适用锁都必须满足。重组可能改变起始确认，因此先前的资格并非不可逆。 [BIP 68 — Relative lock-time] [Bitcoin Core v29.0 — Transaction sequence locks]
CSV 将参数留在栈上，通常随后使用 OP_DROP。签名条件及其他分支决定授权；时间限制既不能找回丢失的密钥，也不排除更早的替代路径。 [BIP 112 — OP_CHECKSEQUENCEVERIFY] [Bitcoin Developer Reference — Transactions]
BIP 112 以 CSV 替代 OP_NOP3，并与 BIP 68/113 规则配合。延迟结束后仍须送达交易并获得确认；费用、数据可用性和链状态依然重要。 [BIP 112 — OP_CHECKSEQUENCEVERIFY] [Bitcoin Core 0.12.1 — BIP 68/112/113 release notes]
要获得更完整的理解，请将本词条与以下词条结合阅读： CHECKLOCKTIMEVERIFY, 比特币脚本操作码, Timelock, Bitcoin Script. 反向关联还来自： 确认, Timelock, 比特币脚本操作码, CHECKLOCKTIMEVERIFY.