专利纠纷中的 Git 提交时间戳证明
在专利纠纷中，代价高昂的问题很少是“这段代码是你写的吗？”而是“你能证明它是何时写的吗？”Git 会为每次提交记录一个日期，但这个日期存在于一个你并不拥有的数据库中，只需一次 rebase 就能改写。专利纠纷中的 Git 提交时间戳证明通过将你的提交历史转化为第三方可以对照比特币区块链进行验证的密码学在先技术，填补了这一空白——而且无需任何人阅读你的源代码。
本文将解释这种证明究竟是什么、它是如何自动生成的，以及它在法律对话中能在哪些方面站得住脚。
什么是 Git 提交时间戳证明？
Git 提交时间戳证明是一种密码学记录，表明某个特定的提交哈希在某个特定时间点存在，并锚定在比特币区块链中。这就是它的全部定义。它不描述你的代码、你的逻辑或你的业务——它证明的是某个指纹在某一时刻的存在。
有必要区分开发者通常混为一谈的两件事：
- Git 中的提交日期。 存储在提交对象中，可通过
git commit --amend或 rebase 修改；如果你使用 GitHub 之类的平台，它还托管在你无法控制的基础设施上。在法律审计中，这类内部日志通常会被视为自利或可篡改而不予采信。 - 比特币锚定的证明。 一种记录，表明该哈希在某个比特币区块被挖出之前就已存在。一旦区块得到确认，任何实体——无论是托管服务商、我们，还是你——都无法更改或倒填其日期。
有一点会让人意外：该证明覆盖的是提交哈希，而非源代码。Timestamp GIT 从不会看到、复制或存储你的实际源代码。它只是对哈希进行数学意义上的时间戳标记，仅此而已。这是设计上的零知识，也正是这种方法可以安全地用于私有乃至商业秘密仓库的原因。
如果你想了解这在知识产权战略中更宏观的定位，面向开发者的知识产权指南涵盖了相关背景；本文则聚焦于时间戳证明本身。
公证人类比：为什么时间戳是证据
想一想公证人。你递交一个密封的信封，公证人在上面盖上日期戳。公证人不会打开信封，不会阅读信件，也不会保留内容副本。这个印章只证明一件事：这个密封物件在该日期存在。
现在把它映射到这个工作流程上：
- 密封的信封就是你的提交哈希——仓库状态的单向 SHA-1/SHA-256 指纹。它不泄露任何内容信息，却与内容唯一绑定。
- 公证人就是比特币。它无法被贿赂，无法被施压去倒填日期戳，对你的业务也毫无看法。
- 你保留的经公证的副本就是
.ots收据文件和清单。证据在你手中，你可以把它交给任何人。
为什么这个类比在法律上重要？因为内部证据的失效模式不是它错了——而是它是你的证据。Git 服务器日志说的是“相信我”。公共区块链锚定说的是“你自己去查，数学在这里”。正是这一差别，把一份提交历史变成了律师可以据以构建在先技术论证的东西。
Timestamp GIT 如何将提交转化为专利纠纷证据
三步模型很直接。
第 1 步——指纹。 当你提交时，Git 会生成一个唯一的单向哈希（SHA-1 或 SHA-256），代表你整个仓库在那一刻的确切状态。这是你工作的密码学安全指纹。
第 2 步——锚定。 Timestamp GIT 只提取提交哈希，按仓库将它们汇集到每日文本清单文件中，生成该清单的 SHA-256 哈希，构建 Merkle 树，并使用 OpenTimestamps 协议将 Merkle 根锚定到一笔比特币交易中。该哈希的存在被冻结在某个特定比特币区块的时间中。
第 3 步——证明。 你会收到一个不可变的 .ots 收据文件。清单和收据会被推送回你自己的仓库——要么放在专门的 timestamps 分支中，要么放在单独的影子仓库中——随时可供律师、审计师或法院使用。
在底层，托管流水线是这样的：
- 提交检测——GitHub App 通过 webhook 检测到新提交。
- 哈希队列——提交哈希进入内存键值存储以进行批处理。
- 午夜 cron 工作进程——每晚，一个工作进程将待处理的哈希分组，写入
.txt清单，构建 Merkle 树，针对公共 OTS 日历创建证明，并将根锚定到比特币中。 - 证明交付——清单和收据回到你的仓库。比特币确认通常需要约三小时，因此证明写入会在批处理运行几小时后完成。
对你的团队来说，重要的部分是：你只需安装一次 GitHub App。 没有 CLI 工具，没有协议命令，没有手动步骤。夜间工作进程会完成其余工作，而且开发者的机器上没有任何需要安装的东西。即便是原始协议方式——自行编排日历和交易——我们也将其视为实现细节，而不是你任何时候都必须运行的工作流程。
对于希望哈希由自己亲手离开其基础设施的团队，Enterprise ZK 模式将 webhook 替换为一个 12 行的 GitHub Action，它在你的 runner 上运行，只将提交哈希推送到 Timestamp GIT API。你的源代码仓库完全不在其中。
为什么这在专利纠纷中很重要（以及人们常犯的错误）
有三种情形反复出现：
- 专利流氓。 非实施实体对常见技术申请宽泛的专利。如果你在其申请日之前数月就已实现该技术并能加以证明，那么被锚定的提交日期就成为可以使该主张无效的在先技术。
- 员工纠纷。 当首席开发者离职时，关于某个功能是何时构思出来的争论就开始了。不可变的时间戳用双方都无法编辑的日期取代了“他说、她说”。
- 净室主张。 竞争对手称他们“独立开发”了类似的东西。证明你在 18 个月前就已拥有完成的逻辑，会筑起一道关于独立开发的说辞无法逾越的数学之墙。
还有三个值得尽早破除的误解：
- “我的 GitHub 提交历史就够了。” 它由你无法控制的第三方托管，而且可编辑。amend、rebase、force-push——日期就变了。
- “我必须公开我的代码才能证明我拥有它。” 不。Timestamp GIT 锚定的是哈希，从不是源代码。你无需披露实现就能获得在先技术证据——这正是商业秘密所需要的。
- “我得自己运行 OpenTimestamps。” 不需要。GitHub App 端到端处理协议，下一节会展示如何检查结果。
验证与呈现证明
验证是本地且零知识的。任何人都可以拿 .ots 文件对照比特币区块链进行检查，而无需信任 Timestamp GIT——也无需我们的公司存在。密码学证明完全依赖 SHA-256 和比特币区块数据。这就是“供应商无关”在实践中的含义：没有专有格式，没有锁定。
在日常使用中，产品以更友好的形式呈现同样的证据：
- 公开验证页面，位于
/verification/{user}/{repo}/{date}——逐步、多级 Merkle 链检查。所有计算都在你的浏览器本地进行。没有人能看到你验证了什么。 - PDF 证书，针对特定日期（
/api/report/{user}/{repo}/{date}），这是你交给法律顾问的凭证。 - 审计 CSV，包含完整账本（
/api/audit/{user}/{repo}），适用于完整的保管链审查。 - README 徽章，公开显示验证状态。投资者和收购方会将这些视为知识产权成熟度的信号。徽章 URL 和 markdown 片段来自
/api/badgeLink/{user}/{repo}。
从脚本快速检查公开状态的方法：
curl -s https://timestampgit.dev/api/statusSummary/acme/payments-service
私有仓库会在 URL 后附加加密的 HMAC，因此只有授权用户才能查看其状态。HMAC 特定于服务器实例。
关于此过程的分步版本——包括如何自行走查 Merkle 链——请参阅如何验证 Git 仓库的比特币时间戳。
部署选项：托管、Enterprise ZK 或自托管
标准模式（GitHub App）。 在仓库上安装该应用。它只读取 HEAD 提交哈希，并将证明写入 timestamps 分支或影子仓库。GitHub 的权限模型意味着我们至少需要对源仓库的只读访问权限（不存在仅限提交哈希的权限），以及对目标仓库的读写访问权限。
Enterprise ZK 模式。 一个 12 行的 GitHub Action 在你的基础设施上运行，只将提交哈希推送到 API。无需对源仓库的读取权限，你的代码永远不会离开你的环境。
Docker 自托管许可证。 为实现最高安全性和气隙环境，Timestamp GIT 以 Docker 镜像形式发布。一个快速开始的 Docker Compose 配置如下：
services:
timestampgit:
image: rue1401/timestampgit:prod
ports:
- "8080:8080"
volumes:
- ./data:/app/data
restart: unless-stopped
valkey:
image: valkey/valkey:8
restart: unless-stopped
docker compose pull
docker compose up -d
docker compose logs -f timestampgit
启动后，应用可在 http://localhost:8080 访问，首次启动时的设置向导会引导你连接 GitHub App。用于评估的限时演示许可证可通过 Docker License 页面上的申请表获取。如果你选择这条路线，自托管 Docker 操作指南涵盖了完整设置。
常见问题
比特币锚定的 Git 提交时间戳在专利纠纷中真的可采信吗？ 它提供基于全球公认密码学标准的法庭可用证据。该证明表明某个提交哈希在特定的比特币区块时间存在，可用于确立在先技术。可采信性取决于你的司法管辖区和你的法律顾问，但密码学证明本身是任何人都可以数学验证的。
Timestamp GIT 会看到或存储我的源代码吗？ 不会。Timestamp GIT 只处理提交哈希。在标准模式下，GitHub App 读取 HEAD 提交哈希；在 Enterprise ZK 模式下，GitHub Action 从你的基础设施只推送哈希，且对源仓库没有读取权限。你的代码留在你的环境中。
我需要在开发者的机器上安装什么吗？ 什么都不需要。Timestamp GIT 是一个托管的 GitHub App。你在仓库上安装一次，每晚每次提交都会被自动锚定。你的团队没有需要学习或记住的 CLI 工具。
保护一个私有仓库需要多少费用？ 公共仓库在开源计划下免费。私有仓库由 Pro Agency 覆盖，每月 49 美元；使用 GitHub Actions 的 Enterprise ZK 为每月 199 美元。还提供用于气隙环境的 Docker 自托管许可证，并附有用于评估的限时演示许可证。
结语
Git 提交时间戳证明将你已经在做的事情——提交代码——转化为你可以据以抗辩的在先技术。仅凭提交历史无法通过法律审计，因为它可编辑且由他人托管。而锚定在比特币中的哈希则可以，因为数学是公开的，记录是不可变的。
实际的做法是不要再把时间戳当作一项手动杂务。安装一次 GitHub App，将它指向重要的仓库，让夜间锚定来完成工作。需要证据时查看状态仪表板，想展示知识产权成熟度时嵌入一个徽章，在真正需要的那一天把 .ots 收据交给你的律师。
相关文章
