OP_CHECKSEQUENCEVERIFY

该操作码从堆栈中读取一个数字，并将其与所花费输入的序列字段进行比较，因此计时从这枚币进入区块时开始，而不是按日历日期计算。BIP-112对其作了定义，网络于2016年7月4日在区块419,328开始强制执行。您开设的每一个闪电网络通道都依赖它。

运作方式

操作码178原为 OP_NOP3，不执行任何操作，因此这条规则是以软分叉而非链分裂的方式进入网络的。

该检查针对三项输入进行：堆栈上的数字、所花费输入的序列字段，以及交易的版本。必须使用版本2或更高版本，因为 BIP-68的相对时间锁规则只从该版本起适用。如果任一数值的最高位被置位，时间锁即被关闭，操作码随即放弃。否则，两者的单位必须一致，且堆栈数值不得超过序列字段。

单位有两种，不能在同一次比较中混用。清除某个特定标志位时，该数字按区块计数；置位时，该数字按512秒的时间间隔计数。两种方式都有十六位可用，因此上限是65,535个区块，约455天，或同样数量的512秒间隔，略少于389天。更长的等待需要改用绝对时间锁。

失败不是延迟，而是拒绝。在等待期结束之前，这笔花费不是排在队列中的待处理交易，而是一笔无效交易，没有节点会转发，也没有矿工会打包。在这枚币足够老之前无需重试，届时同一笔交易就会变为有效。

在哪里会遇到它

闪电网络是按交易量计最大的使用者，该操作码就在保护您这一侧每个通道的脚本中。

通道被单方面关闭时，关闭方的余额会进入一个输出，在延迟期过去之前无法提取，这就是 BOLT 3中的 to_self_delay，通常为几百个区块。设置延迟是为了让对方节点有一段时间发布撤销交易，并在关闭使用了过时状态时取走资金。无论哪种情况您的资金都是安全的，但这正是强制关闭会让您等待一天或更久，而协作关闭则立即付款的原因。

同样的结构也出现在潜水艇交换和原子交换中，在这些场景里，退款路径必须在对手方有合理机会领取之后才能开启；它也出现在恢复钱包中，备份密钥在长期无人操作后才变为可用。

有一个陷阱需要提醒。相对时间锁从所花费的那枚具体的币获得确认时开始计算，因此该币每次移动都会重新开始计时。合并零碎小额输出、转移找零，或让钱包重新整理您的输出，都会使您设置的每一条恢复分支的倒计时重置，原本指望备份密钥下个月生效的继承人可能会发现时钟已归零。

OP_CHECKSEQUENCEVERIFY vs OP_CHECKLOCKTIMEVERIFY

CSV 询问这枚币已存在多久，CLTV 询问现在是几点。这两个操作码在编号上相邻，为178和177，用于截然不同的任务。

截止时间是一个真实日期时，使用绝对形式：例如在2030年解锁的信托，或在已知区块高度到期的退款。等待应在合约开始时起算，无论合约何时开始，则使用相对形式，任何只写一次、反复使用的脚本都需要这样。闪电网络无法对通道延迟使用绝对时间锁，因为今天开设的通道和明年开设的通道需要不同的脚本。这两个操作码的推出也只相隔几个月，CLTV 于2015年12月14日在区块388,381激活，CSV 在次年7月激活，而后者的出现很大程度上是因为前者不足以构建支付通道。