CSV

安娜和彼得可以协商一致后花费共同保管的比特币。他们还想留一条安娜能独自使用的恢复路径，但要从相关输出确认后等待一段时间才能使用。CSV 帮助执行这个条件。CLTV 指向固定高度或时间，而 CSV 的界限并不是整个历史中预先确定的某一点，它取决于具体资金。创建钱包、准备签名，或者让未确认交易等待很久，都不能替代这个起点。钱包是接收和发送比特币的应用程序或设备。 [1] [2] [8]

区块把交易组成一批，加入共同历史记录。区块高度表示区块在链中的位置。假设一个输出在高度 900000 确认，要求的延迟是 10 个区块。按照这个锁定条件，最早能花费它的区块是 900010。只相隔 9 个区块还不够。这不是对准确分钟数的承诺，因为区块并非按固定间隔产生。年龄达标也不等于付款已确认。交易还必须满足其他有效性条件，并由某个矿工真正纳入区块。 [2] [4] [9]

延迟也可以按每档 512 秒编码。数值 2 就表示 1024 秒。但这里比较的不是两台电脑的时钟。起点是确认该输出的区块之前那个区块的 Median Time Past，终点则是候选区块之前那个区块的 Median Time Past。这个指标取最近最多 11 个区块的时间戳，排序后取中间值。两个中位数的差必须达到要求的延迟。这并不是按本地时间精确响起的闹钟。 [2] [4] [7]

钱包付款时，可能合并几笔此前收到的金额。每个交易输入引用此前收到的输出，输出的年龄从它在链上确认时算起。nSequence 字段属于输入本身。这个字段记录相对等待所需的信息。只有部分资金年龄达标还不够，交易中所有适用的锁定条件都必须满足。链重组还可能改变确认发生的位置。因此，曾经具备花费资格并不是资金不可改变的属性。链重组时，网络转而采用另一条有效分支，替换原有区块历史的一部分。 [2] [4] [9]

Full Node 会独立核验规则，并执行相互配合的检查。按照 BIP 112，CSV 将脚本参数与用于花费该输出的输入中的 nSequence 比较。它本身不计算年龄，这由 BIP 68 在交易验证中完成。对未设置禁用标志的普通参数，交易版本至少为 2，且 nSequence 的第 31 位必须未设置。位可以理解为数值字段中的小开关。负参数、较旧版本或不兼容的 nSequence 都会导致检查失败。 [1] [2] [3]

第 22 位决定怎样读取延迟。未设置时，单位是区块；设置时，单位是每档 512 秒。脚本参数和 nSequence 必须使用同一类型。可以把它理解为比较测量结果：如果一边数公里、一边数小时，单看哪个数字大没有意义。这里需要避免的，是混淆区块数量和时间间隔。 [1] [2] [3]

延迟长度放在低 16 位中。掩码 0x0000ffff 用于选取数值字段的这一部分。CSV 比较这部分以及延迟类型，不会把任何较大的 nSequence 都当作更长的等待。选取相关位后，脚本要求不能超过输入中的值。这是钱包设计者需要理解的技术边界；普通用户不应在不理解完整流程的情况下手动设置。 [1] [2] [3]

零延迟不增加等待，但普通 CSV 的其他检查仍然有效。另一种情况是非负的脚本参数本身设置了第 31 位。此时 CSV 的行为像 NOP，即对相对锁定不起作用的指令。这样的参数不强制等待。需要把它与输入 nSequence 中的同一标志区分开：使用普通参数时，输入中的这个标志必须未设置。 [1] [3]

如果安娜的恢复路径需要她的签名，等待结束后她仍须提供。私钥是用于生成这种签名的秘密数值。遗失的私钥不会回来，另一分支也可能仍允许提前花费。执行脚本时，CSV 把参数留在栈中，也就是临时堆放数据的工作区，所以后面常接 OP_DROP 来移除它。但删除这项数据并不授权任何人拿走资金。权限由签名和所选路径的其他条件决定。 [1] [3] [5]

BIP 112 用 CSV 替换 OP_NOP3，并与 BIP 68、BIP 113 一同部署。这是已经可用的功能，不只是计划。例如，Lightning Network 的支付通道会使用它，以延迟为另一方留出反应时间，但指令本身不会替对方作出反应。等待结束后，交易仍须传播和确认。手续费、可用数据和链的状态仍然重要。验证细节见 Bitcoin Core v29.0 及所列规范。 [1] [2] [6]