Bitcoin 时间戳究竟能说明什么。

研究笔记 · 2026 年 9 月 7 日 · Proof21 Commit 是拟议的可选集成。

操作方完成一份报告，希望在之后发生争议时，能证明其内容此前已经固定。Bitcoin 支持的时间戳可以在这里发挥作用。但它支持的陈述比“Bitcoin 验证了这份报告”窄得多。链不会阅读报告的论证、确认作者的诚实，也不会承诺持续提供原始文件。

OpenTimestamps 将时间戳描述为数据在某个时间点之前已经存在的证据，并提供面向后续独立验证的格式。准确使用时，这是一项有价值的基础能力。Proof21 的 Commit 提案应在适当情况下复用成熟的时间戳机制，而不是用更宏大的主张重新包装同一能力。[1]

绑定真正打算保留的产物

从确切字节开始。确定承诺覆盖的是报告、原始证据包、多份产物的清单，还是带版本的组合。记录选定的序列化与摘要算法。如果后来的使用方持有不同文件，对原摘要有效的证明并不能认证替换后的内容。

在一个合成试点中，设想两版报告。第一版记录一项尚未解决的观察；第二版加入额外证据并修订结论。两者都可以是正当记录，但不是同一份产物。应为修订版设置独立标识，并保留关联。不要覆盖第一版，然后把旧时间戳说成也覆盖了新内容。

即使尚未锚定，这种纪律也有用。它让“我们讨论的是哪份报告？”能够得到回答，而不依赖“最终版的最终版”这样的文件名，或智能体的记忆。承诺应帮助保留决策历史，而不是从历史中擦除不方便的不确定性。

提交的请求与已经完成、可验证的时间戳是两种状态。OpenTimestamps 客户端文档描述了需要日历服务信息的不完整证明，以及把通向 Bitcoin 的路径加入证明的升级操作。其记录的本地验证工作流使用 Bitcoin Core 节点。P21 适配器必须说明实际执行了哪一种验证路径。[2]

拟议生命周期应保留原始产物、证明、当前状态、观察时点及任何尚未满足的依赖。获取失败不能变成编造的确认。对证明容器进行离线完整性检查，也不能被描述为对其内部链上证据的完整验证。

不完整证明升级后，应把完成的证明与原始数据一起保存，并测试另一个进程能否验证它。只存在于生成方笔记本电脑上的证明不是可靠交接。保存多个经授权副本可以提高操作韧性，但时间戳本身不是备份服务。

错误陈述与真实陈述一样容易被承诺。时间戳可以帮助确定特定字节在何时之前已经存在，却不能证明所描述的工作发生过、每个事件都已记录，或签名主张是诚实的。这些问题属于证据评估与使用方策略。

Bitcoin 区块时间不是为任意应用事件提供的通用精密时钟。区块头时间戳受共识相关规则约束，并在构造区块时提供。报告不应把它转化成所有链下动作精确的挂钟时间顺序。作为对比，RFC 3161 规定了另一种时间戳机构模型，具有自己的策略与信任假设；它们是不同机制，不是可互换的标签。[3][4]

两份记录可能被聚合到同一个锚点，但这一事实并不能确定两者创建的先后顺序。如果应用需要证明选择承诺早于来源揭示，就必须定义并验证这一特定顺序关系。最终给两份记录都附上时间戳，并不能回答这个问题。

哈希不是完整的隐私策略。在自定义承诺设计中，如果消息只可能来自很小的集合，裸摘要可能被通过逐个猜测来验证。成熟的时间戳工具可能加入保护性随机值，但发布时间、网络请求、证明共享与周边元数据仍然重要。不要移除上游隐私措施，却声称哈希函数没变就保留了同样的保证。

确定谁可以访问原始证据、保留多久，以及经授权使用方如何取得它。不要仅为方便验证就发布个人信息或秘密。摘要不能恢复丢失文档，不能赋予使用方查看权限，也不能保证远程服务器明天还会响应。

试点应测试证据文件丢失、日历服务不可用、证明被修改、产物不匹配、算法不支持和升级中断。报告哪些失败阻止验证，哪些只是阻止获取。这些情况比一条总是终止于绿色锚点的动画线更有说明力。

不是每项验证任务都需要新增 Bitcoin 写入。本地检查可以复现受支持的计算或检测被修改的产物，而不创建交易。聚合可以让一个锚定结构覆盖多份记录，但实现必须保留每份记录的路径与范围，而不能把共享根当成通用证书。

试点要回答的是：独立时间证据是否实质帮助使用方解决真实争议，或执行预先声明的顺序策略。应衡量获取与验证成功情况、未解决状态和操作工作量。不要把合成吞吐量或假定的费用节省说成生产结果。Proof21 目前提供文档和离线教育演示，而不是实时的时间戳端点，也不保证任何用户记录已经锚定。

不能。它可以在时间戳机制的假设下，支持确切数据的存在时间边界。评估报告主张需要独立的证据与规则。

不够。状态必须与实际证明及已执行验证一致。在所需证据可获得并检查完成之前，应保留待处理或未解决状态。

不需要。承诺是具有特定用途的可选能力。受支持的本地检查与离线重放本身不需要新的链上写入、钱包或 P21 代币。