比特币能给你的文件盖章吗？OpenTimestamps 存证原理与验证

存证证明的是”早于”，不是”始于”

时间戳证明只有一个严格成立的结论：某段数据在这个区块被封存之前已经存在。比特币每个区块头里有一个出块时间戳，而工作量证明保证这条链难以事后改写，于是”数据哈希出现在某个区块的交易里”就构成一个可信的上界。至于这份内容具体是哪一天创作的、创作者是谁，链上没有任何信息可以回答。把”不晚于”说成”恰好是”，是使用存证服务时最常见也最危险的语义滑坡。

哈希先行，原文保密

OpenTimestamps 从不上传文件本身。客户端先对文件做哈希，提交给日历服务器的只有一个 32 字节的摘要，返回的 .ots 回执里记录的也是让摘要能沿路径重建到某个区块头所需的一组承诺操作。原文始终在你手里，这决定了它的适用面：合同、软件发布包、研究稿、设计文件都可以先哈希后存证，事后再拿出原文重算哈希来对账。两个边界条件值得提前想清楚。第一，低熵内容可以被暴力猜解：一个只有几百字节的常见格式文件，外人可以枚举候选内容逐个比对摘要，等于间接泄露原文，所以实务上会在文件哈希里掺入一段只有你知道的随机盐。第二，回执与原文缺一不可。日后验证时哪怕哈希、回执、区块数据全部齐全，只要原始文件本身丢了一个字节，证明就失去意义。

默克尔树把海量存证压进一笔交易

如果每人每份文件都单独发一笔链上交易，存证成本没人受得住。OpenTimestamps 的做法是分层聚合：提交请求先按秒归并进小型默克尔树，各日历服务器（例如公开的 alice、bob 日历节点）再把这些承诺的树根统一写进同一笔比特币交易的输出里。一笔交易因此可以同时给成千上万份文件盖章，费用被摊到几乎可以忽略，公开日历也长期靠捐赠维持、不收注册费。代价是时间分辨率：你的摘要不是立刻上链，而是等待聚合交易被打包确认，日历服务器首页会公示平均打包间隔，一般是几十分钟量级，网络拥堵时更久。所以若你的场景要求”证明未来某时刻文件已存在”（例如先密封再招标），务必留出足够的提前量。

一张 .ots 回执里装了什么

回执本质上是一条重建路径：从你的文件摘要出发，一串成对哈希操作（SHA-256 链接）逐级向上，先汇到日历服务器的树根，再进入比特币某笔交易的摘要，最后沿区块默克尔树走到某个区块头。验证算法只做一件事：沿路径重算哈希，得到候选区块头，然后检查这个区块头是否位于当前累计工作量最大的那条链上。是，则证明成立，证明时间即该区块的时间戳。这个设计意味着验证不需要信任任何一家日历服务器，甚至可以完全离线完成。

怎么验证：在线一键与离线自证

最简单的路径是用官方客户端的 ots verify 文件名.ots，客户端会通过本机的比特币节点 RPC 或日历服务器公布的解析服务补全缺失的区块分支。离线路径则适合审计场景：一台同步完成的 Bitcoin Core（裁剪模式即可）通过 RPC 打开，命令会先在本地链数据库里寻找匹配的区块头，全程不需要向任何第三方出示你的文件哈希。验证失败的常见原因并不神秘：聚合交易尚未被确认（回执此时显示 pending）、本机节点同步落后、或原始文件在验证前已经被改动过。逐一排除即可。

它不能证明什么

不要把存证回执当成版权证书。它不建立所有权，不替代公证，也不构成对内容独创性的认定；它只是”当时已存在”这一件事的密码学证据，证明力多少取决于具体场景与法域的采信规则。同样，存证不具名也不指向你：链上只有一段哈希，任何拿到 .ots 回执的人都能公开验证这份哈希何时上链，但无法反推提交者是谁。反过来，如果你希望”以特定身份在某时发布”，就需要把署名信息本身放进被哈希的文件里，再叠加时间戳。

低风险使用清单

先把盐化哈希与原文的完整备份放在一起保管；日历提交后等回执从 pending 转为已确认再归档；跨年度长期保管时，把回执连同当时的区块高度、聚合交易编号一并记录，方便未来审计；重要文件可同时在多个日历留痕，降低单一服务停摆的影响。所有涉及争议解决的场合，存证只应作为证据链的一环，与公证、时间服务机构或可信第三方的记录互相印证。

风险提示：本文仅为密码学工具的原理说明，不构成法律或投资建议；存证回执在纠纷中的采信标准因法域而异，重要事项请咨询专业意见。