Timestamp GIT Secure your prior art without exposing code

← All posts

2026-09-08

如何证明你的代码在特定日期已存在(且不泄露内容)

如何证明你的代码在特定日期已存在(且不泄露内容)
timestamp git blockchain proof

如何证明你的代码在特定日期就已存在(且不泄露代码)

这个任务说起来简单,但要做好却很难:证明某个特定的提交——或整个代码库——在某个给定日期就已存在,同时不公开你的源代码,也不依赖那些法庭可能认为属于“自说自话”的日志。本指南将逐步讲解如何使用 Timestamp GIT 来实现这一目标。Timestamp GIT 是一个托管式 GitHub App,它利用 OpenTimestamps 协议将 Git 提交哈希锚定到比特币区块链上。

读完本文后,你将拥有自动化的、零知识的 Git 历史时间戳方案。每个被监控的提交都会获得一个 .ots 加密回执、一个公开的验证页面,以及一条通向法庭级现有技术证据的路径——全程无需安装 OpenTimestamps 工具,也无需亲自处理比特币交易。

前置条件

开始之前,请确保你具备以下条件:

  • 一个 GitHub 账户。
  • 一个你想要打时间戳的仓库——公开或私有均可。
  • 能够从 timestampgit.dev 安装 Timestamp GIT GitHub App。
  • 基本熟悉 git commit 和 git push。不需要任何密码学或区块链知识。
  • 对于企业零知识模式:需要 Timestamp GIT 提供的 GitHub Actions 工作流文件,以及一个用于写入证明的目标仓库。
  • 可选:如果你需要隔离网络或自托管部署,需要 Timestamp GIT 的 Docker 许可证。

定价与使用场景相匹配:公开仓库可以使用免费套餐,私有仓库由 Pro Agency 套餐覆盖(每月 49 美元),带 GitHub Actions 的企业零知识模式起价为每月 199 美元。

分步指南:设置自动时间戳

第 1 步:安装 Timestamp GIT GitHub App

前往 timestampgit.dev,从 GitHub Marketplace 安装 Timestamp GIT GitHub App。

你授予的权限取决于你的模式:

  • 标准模式:Timestamp GIT 需要对源仓库的只读访问权限,因为 GitHub 不提供“仅提交哈希”这一权限选项。它只读取 HEAD 提交哈希,绝不读取文件内容。
  • 企业零知识模式:Timestamp GIT 完全不需要对源仓库的读取权限。你只需要对存放证明文件的独立目标仓库拥有写入权限。

在两种模式下,目标仓库都会收到一个专用分支或影子仓库,用于存放证明文件。

第 2 步:选择要监控的仓库

安装完成后,打开 timestampgit.dev/repos 上的仓库仪表板。你会看到可以监控的仓库列表。

选择需要自动打时间戳的源仓库。如果你使用独立的影子仓库存放证明,请将其选为目标仓库。

第 3 步:选择部署模式

Timestamp GIT 提供两种模式:

  • 标准模式:GitHub App 通过 webhook 自动检测新提交,只读取提交哈希。
  • 企业零知识模式:一个简短的 GitHub Action 在你自己的基础设施上运行,只将提交哈希推送到 Timestamp GIT API。你的源代码永远不会离开你的环境。

对于大多数团队来说,标准模式是最快的路径。对于有严格合规要求或私有源代码环境,企业零知识模式是更强的零知识选项。

第 4 步:企业零知识模式——添加 GitHub Actions 工作流

如果你选择企业零知识模式,Timestamp GIT 会提供一个 12 行的工作流文件。简化版本如下:

# .github/workflows/timestamp-git.yml
name: timestamp-git

on:
  push:
    branches: ["**"]

jobs:
  timestamp:
    runs-on: ubuntu-latest
    steps:
      - name: Send commit hash to Timestamp GIT
        env:
          TIMESTAMP_GIT_SIGNED_URL: ${{ secrets.TIMESTAMP_GIT_SIGNED_URL }}
        run: |
          curl -f -X POST "$TIMESTAMP_GIT_SIGNED_URL"

实际的工作流使用在 Timestamp GIT 仪表板中生成的签名 URL。该 URL 携带 HMAC 值和提交标识符,因此 Action 从不处理源代码——只处理哈希。

第 5 步:提交一次代码

现在创建一个普通的提交,并将其推送到被监控的仓库:

git add .
git commit -m "feat: add rate limiter"
git push origin main

在标准模式下,GitHub App 通过 webhook 检测到新提交。在企业零知识模式下,GitHub Action 会在推送发生时立即将提交哈希发送到 Timestamp GIT API。

第 6 步:等待夜间批处理

Timestamp GIT 不会实时地逐个锚定每个提交。相反,一个夜间 cron 工作进程会在午夜运行:

  1. 收集所有待处理的提交哈希。
  2. 将它们分组到每日清单文件中。
  3. 构建一棵 Merkle 树。
  4. 使用公共 OTS 日历创建 OpenTimestamps 证明。
  5. 将 Merkle 根锚定到比特币区块链中。

比特币确认通常需要大约三个小时。之后,证明就不可篡改了——任何实体,包括 Timestamp GIT 或你自己,都无法更改它。

第 7 步:获取你的证明

夜间流程完成后,Timestamp GIT 会将清单文件和 .ots 回执文件推送回你的专用时间戳分支或影子仓库。

你也可以直接从 Timestamp GIT 仪表板下载证明文件。主要产物包括:

  • 包含提交哈希的每日清单文件。
  • 每个锚定批次的 .ots 回执文件。
  • 显示比特币区块和交易信息的审计元数据。

如何确认它生效了(验证)

验证是将 Git 哈希转化为你可以拿给律师、审计师或法庭看的东西的关键环节。

查看仓库状态页面

打开 https://timestampgit.dev/status/{user}/{repo}。这个公开仪表板显示:

  • 最新锚定的比特币区块和交易详情。
  • 该仓库最早的锚定日期。
  • 每日时间戳的规律性。
  • 已锚定提交的日历热力图。
  • 可下载的审计 CSV 和 PDF 证书。

运行基于浏览器的 Merkle 验证

对于特定日期,打开 https://timestampgit.dev/verification/{user}/{repo}/{date}。该页面会逐步演示 Merkle 链验证过程。

所有计算都在你的浏览器本地完成。Timestamp GIT 永远不会看到你验证了什么——这是一个零知识验证流程。

下载正式记录

使用仪表板或 API 下载:

  • 特定日期的 PDF 证书。
  • 完整的 审计台账(CSV 格式)。

这些在合同纠纷、知识产权尽职调查和法律取证中非常有用。

在 README 中添加验证徽章

Timestamp GIT 从 https://timestampgit.dev/connected/{user}/{repo} 提供可嵌入的 Shields.io 徽章代码片段。将生成的 Markdown 放入你的 README 中,即可公开展示验证状态。

请注意,私有仓库使用附加在徽章 URL 上的加密 HMAC。只有授权用户才能看到私有仓库的状态。

独立验证

如果你希望在 Timestamp GIT 界面之外进行验证,可以下载 .ots 回执文件,并使用标准的 OpenTimestamps 验证工具对照比特币区块链进行验证。该产品的浏览器验证页面已经为你处理了这些,但回执文件本身永远可以独立验证。

常见问题排查

未检测到提交

检查 GitHub App 是否安装在正确的仓库上,以及是否具有你所在模式所需的权限。在 GitHub 设置中,查看 webhook 投递记录,确认 Timestamp GIT 是否收到了推送事件。

一天后证明仍未出现

请记住,比特币锚定需要几个小时——通常大约三个小时。确认夜间 cron 任务已运行,并且目标分支收到了新文件。如果你使用标准模式,请检查目标仓库是否可写。

徽章显示“未验证”

如果仓库是私有的,除非你使用徽章组件生成的 HMAC 签名 URL,否则公开徽章将无法工作。对于公开仓库,请确保你使用的是 Timestamp GIT 生成的确切代码片段。

企业零知识模式未发送哈希

打开 GitHub Actions 工作流日志,查找错误。确认:

  • 仓库密钥中的签名 URL 仍然有效。
  • 目标仓库可以访问。
  • 工作流在正确的推送事件上运行。

自托管 Docker 实例问题

如果你运行 Docker 镜像,请检查 Compose 配置和日志:

docker compose pull
docker compose up -d
docker compose logs -f timestampgit

同时检查许可证文件是否有效,并挂载在预期位置。启动后,应用可在 http://localhost:8080 访问。

常见问题解答

Timestamp GIT 如何在看不到我的代码的情况下证明代码在某个日期就已存在?

Timestamp GIT 只提取 Git 提交哈希——一种单向加密指纹——并将该哈希锚定到比特币区块链中。实际的源代码永远不会离开你的仓库。由于哈希无法被逆向还原出代码,时间戳证明了该哈希在那一刻就已存在,从而间接证明了代码的存在。

我可以对私有仓库使用 Timestamp GIT 吗?

可以。Timestamp GIT 有针对私有仓库的套餐。在标准模式下,GitHub App 需要对源仓库的读取权限以检测提交哈希,但它从不读取文件内容。在企业零知识模式下,GitHub Action 只将提交哈希发送到 API,因此应用完全无法访问源仓库。

如果 Timestamp GIT 倒闭了怎么办?我还能验证我的时间戳吗?

你的时间戳永远可以验证。证明基于比特币区块链和 OpenTimestamps 协议,两者都独立于 Timestamp GIT。你可以下载 .ots 回执文件,使用标准 OpenTimestamps 工具在本地对照比特币区块链进行验证,完全不依赖 Timestamp GIT 的服务器。

时间戳在法庭上具有法律约束力吗?

没有任何时间戳能保证特定的法律结果。然而,锚定在比特币区块链上的加密时间戳越来越被认可为某一时间点存在的有力证据。它们提供了一种防篡改的、可数学验证的记录,可以在法律程序中提交,以支持现有技术或作者身份的声明。关于在你所在司法管辖区的可采性,你应该咨询法律顾问。

结语

现在你已经使用 Timestamp GIT 为 Git 提交设置好了自动化的、零知识的时间戳方案。你不再需要维护脆弱的内部日志,也不需要手动学习加密协议——只需安装一次 GitHub App,连接一个仓库,然后让夜间流程将提交哈希锚定到比特币中。

其结果是不可篡改的现有技术证明,独立于任何供应商,且在不泄露源代码的情况下生成。从公开仓库的免费套餐开始,或者如果你需要隔离网络基础设施,可以探索 Docker 自托管选项。

如需深入了解,请参阅下面的相关文章。

相关文章

EU label: AI-generated content