CLTV

安娜设计了一种保管方式：日常付款由她和彼得共同批准。如果有人长期无法联系，她还希望保留一条过了指定界限才能使用的备用路径。CLTV 可以把时间条件写入脚本，也就是花费此前收到的比特币所须遵守的规则。单独的 nLockTime 字段只能延迟某一笔交易；CLTV 则不允许用界限更低的新交易绕过这条路径的条件。不过，其他分支仍可采用不同规则。 [1] [5]

CLTV 不识别所有者，也不发送资金。如果恢复路径要求安娜签名，即使时间条件已满足，她也必须提供签名。私钥是用于生成这种签名的秘密数值。时间流逝不会找回遗失的私钥。比特币也不会自行转到另一个地址：必须有人准备、签名并广播一笔有效交易。如果另一分支允许提前花费，恢复分支中的时间锁本身不会限制那条替代路径。 [1]

区块把交易组成一批，加入共同历史记录。CLTV 适合把条件绑定到预先确定的界限，而不是要求“收到这笔比特币后再等若干个区块”。后者由 CSV 与 BIP 68 的相对锁定规则处理，需要考虑特定输出的确认情况。输出可以理解为此前收到的一笔金额及其花费条件。两种方式都无法保证准确的日历日期：出块速度会波动，链重组也可能改变已经确认的历史。链重组时，网络转而采用另一条有效分支，替换原有区块历史的一部分。 [1] [7] [8] [9]

CLTV 区分两类数值。低于 500000000 时，数值表示区块高度，即区块在链中的位置；从这个界限起，数值表示时间戳，也就是用数字记录的时间。脚本条件与花费交易的 nLockTime 必须使用同一类型。因此，不能只看两个数谁大谁小：区块的位置与时间并不是同一种量。 [1] [3] [5]

Full Node 是自行核验规则的完整节点。它会将脚本中非负的界限与交易的绝对 nLockTime 比较。脚本界限不得大于 nLockTime；对于这项检查，相等是允许的。此外，交易还须满足被纳入某个具体区块的规则。CLTV 不读取你电脑上的时钟，也不会暂停程序等到明天。检查失败意味着这次使用该花费路径的尝试无效。 [1] [3] [4]

交易输入指出正在花费哪笔此前收到的比特币，其中包含 nSequence 字段。对于 CLTV 检查的输入，这个字段不能是 0xffffffff，即表示最终序列的特殊值。如果所有输入都使用该值，nLockTime 就可能被禁用。CLTV 要求所检查输入的序列不是最终值，以防止这种绕过。不过，这并不会自动设定某个具体的相对等待时长；那由其他规则负责。 [1] [3] [4]

假设一笔交易的 nLockTime 为 900000，且输入使用非最终序列。仅就这项时间条件而言，最早可被纳入的区块是 900001。因为纳入规则要求 nLockTime 严格小于候选区块的高度。所以，即使 CLTV 内部比较允许相等，区块 900000 仍不满足要求。这里的“最终性”指具备纳入资格，不代表付款已经不可逆。手续费、其他条件和矿工选择仍可能进一步推迟确认。 [4]

对于时间戳，BIP 113 使用前一个区块的 Median Time Past，也就是将最近最多 11 个区块的时间戳排序后取中间值。它不是你的手表时间，也不是当前正在挖掘的区块的时间。基于时间的 nLockTime 必须严格小于该值。因此，不能承诺资金在本地时间正午整点就一定可花费。这是网络能够核验的条件，并非精确的付款日程。 [2] [4]

脚本求值时使用栈，可以把它想成临时堆放数据的工作区。CLTV 只检查时间参数，不将它移除。在一个简单示意结构中，OP_CHECKLOCKTIMEVERIFY 后面因此接 OP_DROP 来移除该参数，然后压入公钥，再由 OP_CHECKSIG 验证签名。公钥用于验证签名，不需要保密。这说明了各指令的作用，并不是可直接用来锁定资金的完整方案。脚本版本、初始数据以及所有其他花费路径也必须正确。 [1] [3]

BIP 65 通过 soft fork 引入 CLTV：它收紧规则，替代了原来的 OP_NOP2。因此，这并非仅供未来考虑的功能。不过，仍须检查整个设计，包括界限类型、nLockTime、nSequence、签名以及其他分支。技术细节可参照 Bitcoin Core v29.0 和所列规范。普通用户最需要弄清的是：界限前后谁能花费资金，以及自己是否理解恢复方式。 [1] [3] [6] [10]