如何在专利申请之前证明你的代码已经存在

这个场景非常残酷：你构建了一个新颖的功能，将其发布在一个私有仓库中，然后继续推进其他工作。十八个月后，一家竞争对手就相同的技术提交了专利申请。如果你无法证明你的实现在他们的申请日之前就已经存在，那么对话就会从“我们先做的”变成“拿出证据来”。本指南将向你展示如何使用 Timestamp GIT 及其托管的 GitHub App，精确地证明你的代码在专利申请之前就已经存在。到最后，你将拥有不可篡改的、锚定在比特币区块链上的 Git 提交时间戳，随时可以支持现有技术抗辩。

困难的方式意味着要学习 OpenTimestamps 协议、运行手动锚定步骤，并维护你自己的证明流水线。Timestamp GIT 消除了这些麻烦：安装一次 GitHub App，连接一个仓库，之后每个提交都会在每晚自动批量处理并锚定到比特币区块链中。

前置条件：开始之前你需要准备什么

你不需要比特币钱包、区块链节点或任何加密工具。你需要的是：

• 一个 GitHub 账户，以及至少一个包含你想要保护的代码的仓库。公共仓库可以使用免费的 Open Source 计划；私有仓库需要付费计划。
• 对 Git 提交和 GitHub 仓库设置的基本熟悉。你应该知道如何推送提交、安装 GitHub App，以及阅读工作流日志。
• 一个 Timestamp GIT 账户。免费层覆盖公共仓库。对于私有仓库，Pro Agency 计划为每月 49 美元，Enterprise ZK Mode 为每月 199 美元。
• 可选：对于隔离或自托管环境，需要一个 Docker 主机。Timestamp GIT 发布了 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

然而，对于大多数开发者来说，托管的 GitHub App 是最快的路径。本指南将遵循这条托管路径。

分步指南：使用 Timestamp GIT 将你的代码锚定到比特币

第 1 步：安装 Timestamp GIT GitHub App

从 Timestamp GIT 仪表板开始，安装 GitHub App。选择你想要监控的目标仓库。在 Standard Mode 下，GitHub 权限系统要求对源仓库具有读取权限，因为 GitHub 无法仅暴露提交哈希。Timestamp GIT 只读取 HEAD 提交哈希，而不读取文件内容。

该 App 还需要对用于存储证明的目标仓库具有写入权限。该目标可以是同一仓库上的专用分支，也可以是一个单独的影子仓库。

第 2 步：配置要监控的仓库

安装完成后，在仪表板中打开仓库列表，为你想要保护的仓库启用监控。启用后，GitHub App 会通过 webhook 检测新提交。无需安装 CLI，无需配置 pre-commit 钩子，也无需学习任何 OpenTimestamps 命令。

每个检测到的提交哈希都会进入内存队列，等待每日处理。Timestamp GIT 不会存储、复制或读取你的源代码。

第 3 步：保持 Standard Mode 或切换到 Enterprise ZK Mode

Standard Mode 对许多团队来说已经足够。GitHub App 会自动读取 HEAD 提交哈希，并将证明文件写回你选择的目标分支。

为了实现最大程度的零知识操作，请选择 Enterprise ZK Mode。一个简短的 GitHub Action 在你的基础设施上运行，仅将提交哈希和提交 ID 推送到 Timestamp GIT API。在这种模式下，Timestamp GIT 完全不需要对源仓库的读取权限。你的源代码永远不会离开你的环境。

你的仪表板会提供确切的 action 代码片段。从概念上讲，该工作流只发送元数据——绝不发送文件、路径、blob 或仓库内容。

第 4 步：让夜间 Cron Worker 锚定你的哈希

Timestamp GIT 每天处理一次待处理的哈希。在午夜，一个 cron worker 会：

• 按仓库对待处理的提交哈希进行分组。
• 为每个仓库创建清单文件。
• 原生构建 Merkle 树。
• 使用公共 OTS 日历创建 OpenTimestamps 证明。
• 将 Merkle 根锚定到比特币区块链中。

每日锚定之后，证明创建会在后台继续进行。比特币确认通常需要大约三个小时，因此证明会在夜间批次开始后的几个小时内出现。你不需要监控这个过程，也不需要手动触发它。

第 5 步：接收不可篡改的证明文件

一旦确认完成，Timestamp GIT 会将证明工件推送回你的仓库。你会看到：

• 一个描述批次和所涵盖提交的清单文件。
• 一个或多个包含加密时间戳证明的 .ots 回执文件。

这些文件存放在专用的 timestamps 分支或影子仓库中，具体取决于你的配置。它们是 Git 中的普通文件，因此易于保存、复制并交给律师。

第 6 步：向你的 README 添加验证徽章

从 Repository Connected 页面复制生成的徽章嵌入代码。它遵循标准的 Shields.io 风格 Markdown 模式：

[![Timestamp status](https://timestampgit.dev/api/statusSummary/{user}/{repo})](https://timestampgit.dev/status/{user}/{repo})

将 {user} 和 {repo} 替换为你实际的 GitHub 账户名和仓库名。该徽章链接到公共状态仪表板，任何人都可以在那里查看最早的锚定日期、每日规律性以及比特币区块数据。

对于私有仓库，徽章 URL 包含加密的 HMAC，因此只有授权用户才能查看状态。

第 7 步：下载 PDF 证书或审计 CSV

对于法律记录，打开 Repository Status 仪表板并下载：

• 特定日期的 PDF 证书。
• 一份 完整审计 CSV，列出所有已加时间戳提交的完整账本。

当你需要一份供律师、投资者或法院提交使用的人类可读记录时，这两者都很有用。底层的 .ots 文件仍然是数学上独立的证明。

如何验证你的时间戳确实生效了

检查 Repository Status 仪表板

公共状态页面是最快的信号。它显示：

• 证明的持久性和最早的锚定日期。
• 每日锚定的规律性。
• 比特币区块高度和交易数据。
• 已加时间戳日期的日历热力图。

如果你看到当前提交日期带有已确认的比特币区块，则锚定已成功。

在浏览器中运行本地验证

/verification/{user}/{repo}/{date} 处的验证页面会在你的浏览器中本地执行逐步的 Merkle 链验证。这意味着验证计算不依赖于 Timestamp GIT 的服务器来证明其自身的结果。你可以沿着加密路径从你的提交哈希一直追踪到比特币区块。

独立验证 .ots 回执

由于证明仅使用 SHA-256 和比特币区块数据，你并不会被锁定在 Timestamp GIT 中。你可以下载 .ots 回执，并使用标准的 OpenTimestamps 验证工具对照比特币区块链进行验证。不需要专有软件，因此即使公司消失，证明仍然有效。

确认 README 徽章

最后，确认 README 中的徽章显示已验证状态，并链接回公共状态页面。该徽章是面向同事、审计员和维护者的一个轻量级外部信号。

常见问题排查

没有提交被加时间戳

首先检查 GitHub App 权限。在 Standard Mode 下，Timestamp GIT 必须对源仓库具有读取权限，并对目标仓库或分支具有写入权限。如果缺少任一权限，就无法读取提交哈希，也无法写入证明。

证明耗时过长

时间戳不是即时的。Timestamp GIT 每晚批量处理哈希，然后将 Merkle 根锚定到比特币中。比特币确认通常在交易广播后需要大约三个小时。证明在确认后写入，因此延迟几个小时是正常的。

私有仓库状态不可见

私有仓库状态 URL 使用与 Timestamp GIT 服务器实例绑定的加密 HMAC。如果状态页面为空白或显示未授权，请确保你在同一实例上已认证，并且使用的是为你的私有仓库生成的链接。

自托管设置失败

对于 Docker 自托管，请验证 Compose 文件是否有效、许可证文件是否正确挂载，以及 valkey 服务是否正在运行。docker compose logs -f timestampgit 输出的 Timestamp GIT 日志是首先要检查的地方。

常见问题解答

比特币时间戳在法律上是否被认可为现有技术？

虽然各司法管辖区的法律有所不同，但加密时间戳为某一特定时间点的存在提供了强有力的证据。Timestamp GIT 使用 OpenTimestamps 协议，该协议将数据锚定到比特币区块链中，使其极难被质疑。请务必就你的具体情况咨询法律顾问。

我需要向 Timestamp GIT 暴露我的源代码吗？

不需要。Timestamp GIT 只处理 Git 提交哈希，绝不处理你的源代码。在 Standard Mode 下，GitHub App 只读取 HEAD 提交哈希。在 Enterprise ZK Mode 下，你基础设施上的 GitHub Action 仅将哈希推送到 API，因此你的代码永远不会离开你的环境。

如果 Timestamp GIT 倒闭了怎么办？我的证明仍然有效吗？

是的。你的证明锚定在比特币区块链中，可以使用标准的 OpenTimestamps 工具独立验证。该证明仅依赖 SHA-256 和比特币区块数据，不涉及任何专有技术或锁定。

我可以将 Timestamp GIT 用于私有仓库吗？

可以，使用每月 49 美元的 Pro Agency 计划或每月 199 美元的 Enterprise ZK 计划。私有仓库状态 URL 受加密 HMAC 保护，因此只有授权用户才能查看时间戳状态。

结论：今天就保护好你的现有技术

你现在拥有一个可重复的工作流，用于证明代码在专利申请之前就已经存在。连接 GitHub App，让夜间锚定自动运行，然后收集 .ots 回执、PDF 证书和审计日志。其结果是形成一个加密的现有技术护盾，它不依赖于你自己的日志、第三方服务器或 Timestamp GIT 的持续存在。

立即安装 Timestamp GIT GitHub App 并连接你的第一个仓库。公共仓库可以免费开始使用；私有仓库由 Pro Agency 或 Enterprise ZK 计划覆盖。对于隔离环境，可以申请 Docker 演示许可证并在本地自托管相同的流水线。下一次专利主张在升级之前，就应该先面对你的证明。

如需更全面地了解为什么这在诉讼和许可压力中至关重要，请参阅 Timestamp Git Commits to Defend Against Patent Trolls。

相关文章

• Timestamp Git Commits to Defend Against Patent Trolls
• Automate Code Timestamping with a GitHub App
• The Best GitHub App for Timestamping Your Commits