Timelock

Anna 和 Pavel 可以把共同资金设置为：两人随时都能一起花费，但 Anna 要独自花费，就必须等过一段延迟。如果 Pavel 不再回应，这条延迟分支便提供了事先约定的取回路径。这里的分支是指一种获准的花费方式，每种方式可以有不同条件。因此，时间锁不一定同时堵住所有路径。这些规则必须在输出创建时就成为它的一部分。事后在普通钱包里加一句“一周后解锁”的备注并不够。等待结束后，Anna 仍然需要相应的密钥，以及构造有效交易所需的信息。Timelock 可以管理访问权限，却不能找回丢失的密钥。 [3]

绝对锁定规定一个固定界限，记录在交易的 nLockTime 字段中。如果交易中生效的 nLockTime 设为区块高度 1 000 000，那么最早满足这个条件的区块是 1 000 001：相等还不够。相对锁定则从被花费输出的确认开始计算延迟。如果 Anna 的输出创建于区块 1 000 000，相应分支要求等待 6 个区块，那么花费它最早可在区块 1 000 006 满足这个条件。这些数字只是例子，不是当前网络高度。签名、其他输入以及可能存在的其他锁定条件仍然要满足。六个区块也不等于恰好一小时，因为出块间隔并不均匀。相对等待不是从创建钱包开始，也不是从 Anna 决定使用资金时开始。 [1] [2] [5]

假设 Anna 所需的延迟刚刚结束。网络不会代替她行动。仍然需要有人构造交易或使用准备好的交易，提供签名、支付手续费，并把交易提交到网络。之后矿工才可能将它纳入区块。满足 Timelock 只是满足了一个条件，不是预订区块位置，也不是自动转账。它通常规定的是某种花费方式何时开始可用，而不是何时自动失效。链重组是指链的一部分被另一条有效分支替代。这可能改变输出的确认情况及相对延迟的计算。自行设计这类方案时，要事先核对所有分支、钱包支持，以及密钥和花费规则的备份；时间不会修复设错的条件。 [2] [5]

按时间计算的条件使用 Median Time Past，简称 MTP。对于正在验证的区块，它是截至前一个区块为止，最近 11 个区块时间戳的中位数。把这些时间排序，取中间的第六个，就是中位数，不是算术平均数。BIP113 描述了这条规则，Bitcoin Core 用 GetMedianTimePast 计算。因此，判断依据既不是 Anna 手机上的当前时间，也不是候选区块自己的时间戳。日历上的午夜，不一定就是时间锁满足的时刻。按高度锁定则等待区块，并不倒数秒数。 [4]

现在可以区分文档里的四个名称。nLockTime 是整笔交易中的字段，用于绝对界限。输入上的 nSequence 按 BIP68 表达相对延迟。但单独的 nLockTime 不能锁住一个 UTXO，也就是尚未花费的输出，阻止另一笔采用不同设置的交易花费它。只要输出规则不阻止，有权花费的人仍可创建另一笔交易。Bitcoin Script 是表达这些花费规则的语言。OP_CHECKLOCKTIMEVERIFY，简称 CLTV，按照 BIP65 在所用分支中要求相应的绝对设置。OP_CHECKSEQUENCEVERIFY，也就是 BIP112 中的 CSV，检查相对设置；真正经过的延迟由 BIP68 约束。CLTV 和 CSV 都不会发送资金或补上缺失的签名。另一条获准分支可能在不同条件下就能使用。 [1] [2] [3]

以下是技术参考部分。字段是存储在交易中的数据项；输入引用将被花费的输出。每个输入都有 nSequence。某个特殊值可以关闭 nLockTime 的作用，因此只填入日期还不够。 nLockTime 是无符号 32 位字段；零关闭绝对时间条件。如果所有输入均采用值为 0xffffffff 的 SEQUENCE_FINAL，未满足的 nLockTime 会被忽略。有效的绝对锁定要求至少一个输入采用其他 nSequence。这里评估的是这笔具体交易，并非永久冻结其输入。 [5] [7]

同一字段能表达两种不同含义，需要一个数值门槛来区分。Unix timestamp 以从 UTC 1970 年初开始经过的秒数表示时间。候选区块就是正在验证的交易准备被纳入的区块。 LOCKTIME_THRESHOLD 的值为 500000000。更小的 nLockTime 表示区块高度，等于或大于该值则表示 Unix timestamp。启用绝对检查时，nLockTime 必须严格小于候选区块高度或相应 MTP。相等不足以通过；它不是金额、平均高度或协议激活日期。 [5] [8]

操作数是传给指令的值；opcode 则是 Script 指令本身。CLTV 比较分支中保存的要求与交易设置。链是否已经推进得足够远，由另一项检查判断。这不只是把今天的日期与某个数字比较。 OP_CHECKLOCKTIMEVERIFY 要求操作数非负，与 nLockTime 的高度/时间类型相同，且不大于 nLockTime。对应花费输入的 nSequence 不能是 0xffffffff。该 opcode 不直接读取时钟或链高度；交易设置会在检查其时间有效性时另行评估。Script 的其他条件仍须满足。 [1] [6]

nSequence 这个数字既包含等待长度，也包含决定其含义的开关。比特位是这种表示中的零或一，设置它可以启用某个选项。下面的位位置属于技术格式，不是确认次数。 对版本为 2 或更高的交易，BIP68 为未设置第 31 位的输入启用相对条件。低 16 位规定延迟；第 22 位选择以 512 秒为单位，否则以区块为单位。区块延迟从被花费输出的确认高度起算。时间延迟从该确认区块之前一个区块的 MTP，计算到候选区块之前一个区块的 MTP。它不是从钱包创建交易时开始计时。 [2] [5]

CSV 对相对等待做类似检查。掩码用于选出相关的 nSequence 位；disable flag 是关闭开关。Lightning Network 是由支付通道组成的网络，参与者不断更新共同锁定资金的分配约定。如果有人公布已撤销的旧状态，这段延迟就给另一方留下应对时间。commitment transaction 记录资金分配；撤销密钥让另一方可以通过惩罚分支花费已撤销版本中的相应输出。 当操作数非负且启用相对检查时，OP_CHECKSEQUENCEVERIFY 要求版本至少为 2、输入的 disable flag 未设置、延迟类型相同，且掩码处理后的 nSequence 足够大。实际年龄由 BIP68 另行强制检查。CSV 可实现延迟恢复分支。对于 Lightning 的 to_local 输出，to_self_delay 约束 commitment transaction 的所有者；掌握正确撤销密钥的对手方可使用惩罚分支，无须等待该延迟。 [3] [9]

两个几乎一样的数字可能有不同作用。下面以 0x 开头的值用十六进制表示。NOP 指这里不会增加时间限制的指令。开关位于交易输入中，还是位于传给 CSV 的值中，也同样重要。 第 31 位是 SEQUENCE_LOCKTIME_DISABLE_FLAG，仅关闭该输入的 BIP68 相对解释。0xfffffffe 包含此位，却不是 SEQUENCE_FINAL，因此仍可有效使用 nLockTime 和 CLTV。0xffffffff 才是 final。设置了 disable flag 的非负 CSV 操作数按 NOP 处理；但若在输入中设置该标志，就无法满足启用状态的 CSV 要求。两种情况不能混淆。 [3] [7]

RPC 是向自己的节点发出的命令。节点是验证比特币区块和交易的程序。解码只是把存储的数据转成可读列表；测试命令随后检查某笔已签名交易是否能通过。Mempool 是这个节点本地保存的待确认交易列表。 Core 31 的 decoderawtransaction RPC 显示 version、locktime 和每个输入的 sequence。对于 CLTV/CSV，应检查实际使用的 Script 和被花费的输出；仅解码并不能证明有效。testmempoolaccept RPC 根据当前链状态、比特币的有效性规则及节点本地的交易接收规则，对已签名候选交易进行测试，不将其接受进 mempool，也不广播。应检查 allowed 及拒绝原因；通过测试不代表承诺未来确认。 [10] [11] [12]