区块链/等级 IV · 深入协议/4.1 Script/课程 4

时间锁：CLTV与CSV

无法倒转的时钟，以及让它保持公正的中位数

材料提供交易详情查看功能的区块浏览器（例如 mempool.space 或 blockchain.com）一种能够处理 Unix 时间戳的计算器BIP65、BIP68和BIP113规范文档

好奇

既然新交易总能绕过它，那为何还要设置用于延迟支出的交易字段呢？
单个矿工如何在不破坏其他所有人共识的情况下篡改时间？
等到特定年份与从现在起等待两年，有什么区别？

探索

每笔比特币交易都带有一个 nLockTime 字段，这是一个四字节的数值，用于阻止该交易在某个时间点之前被打包进区块。如果该数值低于500,000,000，则表示区块高度；若达到或超过这一阈值，则为 Unix 时间戳。然而，这一机制只作用于这笔交易本身。用户总可以用相同的输入另建一笔锁定时间为零的新交易，立即花费这些币。仅靠 nLockTime 无法为未来的条件提供任何安全保障，因为它并不约束输出本身。
OP_CHECKLOCKTIMEVERIFY（CLTV）由 Peter Todd 在 BIP65 中提出，于2015年12月激活，改变了这一局面。CLTV 是一个脚本操作码，它将交易的 nLockTime 与栈上的数值进行比较；如果锁定时间小于所要求的值，执行即失败。由于这一检查发生在输出的锁定脚本中，任何试图花费该未花费交易输出（UTXO）的行为都必须满足这一条件。这就形成了绝对时间锁：在达到全网共识的某个时间点或区块高度之前，这些币无法被花费。
相对时间锁的运作方式不同，它衡量的是时长而非绝对时间点。BIP68 重新解释了交易输入中的 nSequence 字段（此前并未用于此目的），用它来编码相对延迟。OP_CHECKSEQUENCEVERIFY（CSV）由 BIP112 定义，于2016年7月与 BIP68 一同激活，它将输入的序列值与所要求的时长进行比较。这使脚本能够强制执行诸如“该输出在确认后144个区块之内不得花费”之类的条件。延迟是相对于该 UTXO 的确认而言的，因此非常适合基于时间的恢复路径或支付通道的到期处理。
基于时间的锁也让矿工有了操纵时间戳的动机。矿工可以把区块时间戳设到最多两小时之后，从而比预期更早地打包更多带时间锁的交易。2016年7月与相对时间锁同时激活的 BIP113 引入了过去时间中位数（MTP）。时间锁检查现在以过去十一个区块时间戳的中位数为准，而非区块自身的时间戳。这确保任何单个矿工都无法显著影响这一时钟；MTP 通常比实际时间慢约一小时，为所有时间锁计算提供稳定且可验证的参照。
这些机制是支付通道和继承协议等复杂应用的基础。在闪电网络通道中，在途支付使用绝对时间锁（CLTV），这样未被领取的支付可在截止时间后退款；而一方自身输出上的相对延迟（CSV）则让另一方有时间惩罚过时的通道状态。在继承方面，脚本可以将多签要求与时间锁结合：例如日常使用需要两把密钥，但在一年无活动后，第三把密钥（继承人）通过 CSV 条件加入签名法定人数。这些参数在创建钱包时即已确定，资金一旦锁定便无法更改。
时间锁是永久性的约束：它们在设定的时间解锁，但生效后没有任何机制可以重新锁定或延长延迟。如果脚本编码的序列值为100个区块，那么从确认起到达该相对高度时，这些币恰好变为可花费。编码错误可能使资金被锁定得比预期更久，或者反过来过早解锁。如需亲手验证，可在区块浏览器上打开任意一笔近期交易，查看 nLockTime 字段。大多数钱包会将其设为当前区块高度，这样该交易就无法被放入更早高度的区块中；这消除了矿工为收取手续费而重写最新区块的一个动机（即“费用狙击”，fee sniping）。