相对时间锁

BIP-68赋予每个输入上的四字节序列号字段以共识含义，但仅适用于声明版本为2或更高的交易。该规则通过位于第0位的 BIP-9 versionbits 部署进入网络，该部署于2016年5月1日开启，并与 BIP-112和 BIP-113一同上线。如果您持有的币位于恢复脚本或通道脚本之后，每次这些币发生移动，倒计时都会重新开始。

运作方式

相对时间锁编码在序列号字段中，最高位决定是否会产生任何效果。

当第31位被置位时，该字段不具有共识含义，输入可以进入任何区块。当第31位未置位时，节点用0x0000ffff 对该字段取掩码，并将保留下来的16位读作等待期。第22位决定单位。未置位时，该数字按区块计数，BIP-68给出的范围是0至65,535个区块，并称之为1.25年。置位时，该数字按每个512秒的周期计数，BIP 将这一范围表述为不到33,554,431秒，约1.06年。选择512这个特殊数值，是因为区块大约每600秒产生一个，所以两种单位在相同的16位中覆盖的跨度相近。

携带以区块为单位的值 n 的输入，可以在其所花费的输出被挖出的区块之后 n 个区块被打包，因此值为1时在紧接着的下一个区块即可满足，而不是再下一个。以时间为单位的值从不与时钟比较。BIP-68从挖出该输出的区块的前一个区块的过去中位时间开始计量，并与正在构建的区块的前一个区块的过去中位时间比较，而 BIP-113将这一数值定义为最近11个区块时间戳的中位数。之所以使用中位数而不是原始时间戳，是因为共识规则保证中位数单调递增，这样矿工就无法通过谎报区块时间来多收取手续费。

有两项例外需要注意。这些规则从不适用于 coinbase 交易输入的序列号字段。此外，第16位至第21位这六个位置被保留为未定义，以便日后的软分叉可以在不新增字段的情况下提高粒度或上限。

在哪里会遇到它

BIP-112通过一个在注资后30天超时的担保托管合约来演示相对时间锁。

Alice、Bob 和一名担保托管代理共用一个2-of-3脚本。任意两人可随时花费；延迟期过后，Alice 可单独签名。该 BIP 对触发条件的表述很直接：在向担保托管地址的付款得到确认之前，时钟不会开始计时。这正是它与日历截止日期的全部区别，也是同一个脚本可用于每一笔新的担保托管而无需重写的原因。

该规则还影响内存池的行为。Bitcoin Core 对序列锁的检查依据的是下一个区块的高度，而不是当前链尖的高度，并将未确认的父交易视为将在该区块中确认，因此等待期随下一个区块到期的花费会略早于其可花费时间被转发。除这一余量之外并不存在队列：未成熟的花费是无效的，而不是待处理的。

相对时间锁 vs OP_CHECKSEQUENCEVERIFY

相对时间锁存在于交易输入上，而 OP_CHECKSEQUENCEVERIFY 存在于币的脚本中，用于检查花费它的输入是否遵守了某个相对时间锁。

BIP-68本身不约束任何人。构建花费交易的人自行选择序列号的值，因此写在那里的延迟只是一种偏好，而不是交易对手可以依赖的规则。BIP-112通过使该字段可以从脚本中读取来弥补这一缺口：如果交易版本低于2，如果输入的序列号设置了禁用标志，如果两个值的单位不一致，或者栈上的数字超过经掩码处理后的序列号，该操作码就会失败。栈上的值本身带有禁用标志时，该操作码的行为等同于 NOP，这是为日后的软分叉有意预留的空间。只有具备这些检查，等待期才会成为担保托管代理或闪电网络对等方可以依赖的东西。