比特币时间锁：推导受限花费何时具备资格

比特币时间锁是交易有效性条件，不是项目方承诺的代币释放日期。判断受限花费是否具备资格，要结合脚本、交易字段、确认历史和拟纳入区块。一个日历标签不能证明所有条件已经满足。

BIP 68规定了通过交易序列字段表达相对时间锁的语义。解释字段前应检查版本、标志和编码条件。下例只用区块高度条件；按时间的锁需要自己的共识时钟，不能简单换成墙上时钟倒计时。

列出全部适用条件

确认旧输出引用、创建区块、花费脚本、候选交易版本和字段。绝对条件与相对条件分开：前者指向固定高度或共识时间阈值，后者依赖被引用输出按规则累计的年龄。

不能假设序列号非零就一定启用相对锁。其含义受版本、标志位和编码影响。所选脚本分支还可能要求签名、哈希原像或其他条件；等候期满足只是有效性的一个部分。

按高度分析时，将每项写成候选纳入高度H的不等式，严格大于和大于等于不能混用。“X区块解锁”若不说明X本身是否有效，容易出现一块的误差。

假设虚构输出在1000高度确认，正确解码的相对条件允许H≥1010时花费。同一候选交易另有生效的绝对条件H>1050。这些是本例明确给定的条件，不是所有脚本的默认规则。

候选高度	相对条件	绝对条件	合并高度资格
1009	不满足	不满足	否
1010	满足	不满足	否
1050	满足	不满足	否
1051	满足	满足	是，仍需其他条件

最早同时通过的是1051，而不是1010。不能只因其中一个锁已结束，就取更早日期。合并测试是全部条件同时满足。

再假设输出实际改在1045高度确认，仍有相对十区块条件，那么相对边界变成H≥1055，合并最早高度也变成1055。相对锁随起点确认移动，只看绝对倒计时就会漏掉这个依赖。

时间型限制应注明适用的过去时间中位数参照和编码时间单位。不要把预计区块数换成保证某日某时可花费，出块间隔会变化，共识时钟也有专门定义。

保留链参照，相关重组后重跑。如果输入确认历史改变，相对条件可能需要重新计算。已移除分支中的创建高度，不能直接拿来证明选定链上的资格。

高度或时间通过后，还需验证目标参与者是否能满足其余脚本。成熟退款分支可能只对某一方开放，另一方仍不能使用。公开脚本也不能证明必要密钥或秘密仍由某人掌握。

交付物是条件表、给定链上的最早资格边界和剩余访问要求。它不保证立即纳入，不给出法律权利意见，也不预测卖压。候选交易、确认历史或所用分支改变时，应重新核对。

多输入交易要逐个检查。一项输入通过，不会让另一项仍未满足相对锁的整笔交易有效。保存逐输入计算，指出真正限制纳入的条件。交易汇总应从这些行推导，不能只挑最宽松输入，也不能拿钱包最老输出替所有输入决定时间。存在不同脚本分支时，还应明确候选实际使用哪条。

还要区分候选交易现在是否有效与过去是否有效；后来达到高度阈值，不能倒推旧区块中的同一候选当时也能被合法纳入。

不能。其余脚本与交易条件、密钥访问和实际区块纳入仍然重要。

只能给依赖确认与时钟假设的情景，真正资格由起点和实际共识条件决定。