Peter Todd

假设你需要证明：合同的某个版本在争议发生之前就已存在。与 Peter Todd 有关的 OpenTimestamps 项目正是为这类问题提供帮助。他在 2016 年的历史公告中发布了公开测试版本，并感谢 Riccardo Casatta 参与开发和测试。这记录了当时的合作，并不表示项目至今仍停留在试验阶段。Todd 还研究了未来支出的条件，以及如何处理尚未确认的付款。我们先从这两个方面说起。 [1]

Todd 的 BIP 65 引入了 OP_CHECKLOCKTIMEVERIFY，简称 CLTV。这条指令可以要求某条特定支出路径等到指定区块高度或时间界限后才能使用。比如，共同储蓄可以设置一条备用取款路径，让收款人以后才能动用。在此之前，时间条件会阻止使用这条路径。条件满足后，币也不会自行转出：仍需创建有效交易，并满足签名等其他要求。如果还存在另一条支出路径，它遵循自己的条件，不能认为这个时间锁一定限制了全部支出方式。 [2]

时间锁并非简单地看钱包屏幕上的时钟。BIP 65 会检查脚本——规定支出条件的指令——与交易中 nLockTime 字段的关系。两者必须采用同一种界限：区块高度或时间。对应输入的 nSequence 也不能使用会使这项检查失效的最终值。这是绝对界限，并不是从输出确认后开始计算的相对年龄。即使条件已经满足，也不代表交易会在某个准确的秒数被打包；矿工仍需把它加入有效区块。 [2]

广播后的交易可能留在 mempool，也就是某个节点保存的未确认交易集合中。如果手续费上涨，发送人可能希望用替换交易提高报价。David A. Harding 和 Peter Todd 在 BIP 125 中描述了最初的 opt-in 替换规则，即通过信号表明允许替换。这个信号可以由 nSequence 给出，也可以从尚未确认的祖先交易继承：当前付款花费了前面交易的输出，因此受其影响。规则并非只看孤立的一笔付款。提高费用可能有帮助，却不能保证立即确认。 [3]

mempool 中的替换改变的是节点保留哪笔交易作为待确认候选，并不会改写已经确认的历史。此外，BIP 125 描述的是历史上的 opt-in 策略，而不是所有软件版本永远不变的规则。后来的 Bitcoin Core 版本把不要求这种信号的替换作为标准行为，同时仍对接受替换交易设置条件。对收款人来说，关键是：没有替换信号本身，不能证明付款已经最终完成。钱包显示“已发送”，也不同于交易已经进入确认的区块。 [3] [6]

回到合同的例子。OpenTimestamps 能生成可验证的证据，表明特定数据在有证据支持的时间界限之前就已存在。它使用 hash，即内容的简短数字指纹，并把证明锚定到 Bitcoin。修改文件后，验证时计算出的指纹会不同。但时间戳本身不能证明作者身份、内容真实性或文件生成的准确时刻。一个人也可以提前给虚假文本加上时间戳。证明限制的是这些数据最晚可能何时出现，并不能说明此前已经存在了多久。 [1] [4]

OpenTimestamps 客户端不会把文件本身发送给日历服务器，而是结合随机值处理文件指纹，使服务器不能从收到的数据推断文件内容。这里的日历是一种收集请求、帮助将其锚定到 Bitcoin 的服务。不过，保护内容不等于完全匿名：相近的时间，或一起生成的证明，可能暴露请求间的关联。生成的 .ots 文件不是原文件的备份。应把它与完全一致的原文件一起保存；指纹无法恢复丢失的文字，修改过的副本也已经是另一份数据。 [5]

新建的时间戳可能尚未锚定到已经确认的 Bitcoin 区块。因此，仅有 .ots 文件不能说明整个过程已完成。OpenTimestamps 客户端区分待完成证明与包含完整区块路径的证明。ots upgrade 命令可以在补充信息可用时下载并保存它，却不能强迫矿工挖出区块。之后还要结合原始数据和 Bitcoin 链验证证明。与等待确认的付款一样，真正重要的是实际状态，而不只是出现了一个文件或通知。 [5]