Timestamp GIT Secure your prior art without exposing code

← Todos os artigos

2026-10-07

Prova de Carimbo de Data/Hora de Commit Git para Disputas de Patentes

Prova de Carimbo de Data/Hora de Commit Git para Disputas de Patentes
timestamp git blockchain proof

Prova de Carimbo de Data/Hora de Commit Git para Disputas de Patentes

Em uma disputa de patente, a pergunta cara raramente é “você escreveu este código?”. É “você consegue provar quando?”. O Git registra uma data em cada commit, mas essa data vive em um banco de dados que você não possui e pode reescrever com um único rebase. Uma prova de carimbo de data/hora de commit Git para disputas de patentes resolve essa lacuna ao transformar seu histórico de commits em prior art criptográfico que um terceiro pode verificar na blockchain do Bitcoin — sem que ninguém leia seu código-fonte.

Este artigo explica o que essa prova realmente é, como ela é produzida automaticamente e onde ela se sustenta em uma conversa jurídica.

O Que É uma Prova de Carimbo de Data/Hora de Commit Git?

Uma prova de carimbo de data/hora de commit Git é um registro criptográfico que mostra que um hash de commit específico existia em um ponto específico no tempo, ancorado na blockchain do Bitcoin. Essa é toda a definição. Ela não descreve seu código, sua lógica ou seu negócio — ela prova a existência de uma impressão digital em um momento no tempo.

Ajuda separar duas coisas que os desenvolvedores geralmente confundem:

  • A data do commit no Git. Armazenada no objeto de commit, editável com git commit --amend ou um rebase, e hospedada em infraestrutura que você não controla se usar uma plataforma como o GitHub. Em uma auditoria jurídica, registros internos como este são rotineiramente descartados como tendenciosos ou manipuláveis.
  • Uma prova ancorada no Bitcoin. Um registro de que o hash existia antes de um determinado bloco do Bitcoin ser minerado. Uma vez que um bloco é confirmado, nenhuma entidade — nem o provedor de hospedagem, nem nós, nem você — pode alterá-lo ou retroagi-lo.

Um ponto que surpreende as pessoas: a prova cobre o hash do commit, não o código-fonte. O Timestamp GIT nunca vê, copia ou armazena seu código-fonte real. Ele carimba matematicamente o hash e nada mais. Isso é zero-knowledge por design, e é o que torna toda a abordagem segura para uso em repositórios privados e até mesmo de segredos comerciais.

Se você quiser o panorama mais amplo de como isso se encaixa em uma estratégia de PI, o guia de propriedade intelectual para desenvolvedores cobre o terreno ao redor; este artigo se mantém na própria prova de carimbo de data/hora.

A Analogia do Tabelião: Por Que um Carimbo de Data/Hora É Evidência

Pense em um tabelião. Você entrega um envelope lacrado, e o tabelião carimba a data nele. O tabelião não abre o envelope, não lê a carta e não guarda uma cópia do conteúdo. O carimbo certifica apenas uma coisa: este objeto lacrado existia nesta data.

Agora mapeie isso para este fluxo de trabalho:

  • O envelope lacrado é o hash do seu commit — uma impressão digital unidirecional SHA-1/SHA-256 do estado do repositório. Ela não revela nada sobre o conteúdo, mas está unicamente vinculada a ele.
  • O tabelião é o Bitcoin. Ele não pode ser subornado, não pode ser pressionado a retroagir um carimbo e não tem opinião sobre o seu negócio.
  • A cópia carbono tabelionada que você guarda é o arquivo de recibo .ots e o manifesto. Você detém a evidência, e pode entregá-la a qualquer pessoa.

Por que a analogia importa juridicamente? Porque o modo de falha da evidência interna não é que ela esteja errada — é que ela é sua evidência. Um log de servidor Git diz “confie em mim”. Uma âncora em blockchain pública diz “verifique você mesmo, aqui está a matemática”. Essa diferença é o que transforma um histórico de commits em algo sobre o qual um advogado pode construir um argumento de prior art.

Como o Timestamp GIT Transforma Commits em Evidência para Disputas de Patentes

O modelo de três etapas é direto.

Etapa 1 — Impressão digital. Quando você faz um commit, o Git gera um hash unidirecional único (SHA-1 ou SHA-256) representando o estado exato de todo o seu repositório naquele momento. Esta é uma impressão digital criptograficamente segura do seu trabalho.

Etapa 2 — Ancoragem. O Timestamp GIT extrai apenas os hashes de commit, os coleta em um arquivo de manifesto de texto diário por repositório, gera um hash SHA-256 desse manifesto, constrói uma árvore de Merkle e ancora a raiz de Merkle em uma transação Bitcoin usando o protocolo OpenTimestamps. A existência do hash é congelada no tempo em um bloco específico do Bitcoin.

Etapa 3 — Prova. Você recebe um arquivo de recibo .ots imutável. O manifesto e os recibos são enviados de volta para o seu próprio repositório — seja em um branch dedicado timestamps ou em um repositório sombra separado — prontos para um advogado, auditor ou tribunal.

Nos bastidores, o pipeline gerenciado funciona assim:

  1. Detecção de commit — o GitHub App detecta novos commits via webhooks.
  2. Fila de hashes — os hashes de commit vão para um armazenamento chave-valor em memória para agrupamento em lote.
  3. Worker cron da meia-noite — a cada noite, um worker agrupa os hashes pendentes, escreve os manifestos .txt, constrói a árvore de Merkle, cria as provas contra os calendários públicos do OTS e ancora a raiz no Bitcoin.
  4. Entrega da prova — manifestos e recibos retornam ao seu repositório. A confirmação do Bitcoin normalmente leva cerca de três horas, então a gravação da prova termina algumas horas após a execução do lote.

A parte importante para sua equipe: você instala o GitHub App uma vez. Não há ferramentas de CLI, nem comandos de protocolo, nem etapas manuais. O worker noturno faz o resto, e não há nada para instalar nas máquinas dos seus desenvolvedores. Até mesmo a abordagem de protocolo bruto — orquestrar os calendários e transações por conta própria — é algo que tratamos como um detalhe de implementação, e não como um fluxo de trabalho que você deva ter que executar.

Para equipes que querem que o hash saia da sua infraestrutura por sua própria mão, o modo Enterprise ZK troca o webhook por uma GitHub Action de 12 linhas que roda nos seus runners e envia apenas o hash do commit para a API do Timestamp GIT. Seu repositório de código-fonte fica completamente fora da equação.

Por Que Isso Importa em uma Disputa de Patentes (e o Que as Pessoas Erram)

Três cenários surgem repetidamente:

  • Trolls de patentes. Entidades não praticantes registram patentes amplas sobre tecnologias comuns. Se você implementou essa tecnologia meses antes da data de depósito delas e consegue provar isso, a data de commit ancorada se torna prior art que pode invalidar a reivindicação.
  • Disputas trabalhistas. Quando um desenvolvedor líder sai, começam as discussões sobre quando um recurso foi concebido. Um carimbo de data/hora imutável substitui o “ele disse, ela disse” por uma data que nenhum dos lados pode editar.
  • Alegações de clean-room. Um concorrente diz que “desenvolveu independentemente” algo semelhante. Provar que você tinha a lógica finalizada 18 meses antes cria uma parede matemática que uma história sobre desenvolvimento independente não consegue escalar.

E três equívocos que vale a pena eliminar desde cedo:

  • “Meu histórico de commits do GitHub é suficiente.” Ele é hospedado por um terceiro que você não controla, e é editável. Amend, rebase, force-push — as datas mudam.
  • “Eu tenho que publicar meu código para provar que o tinha.” Não. O Timestamp GIT ancora o hash, nunca o código-fonte. Você obtém evidência de prior art sem divulgar a implementação — que é exatamente o que você quer para segredos comerciais.
  • “Eu teria que rodar o OpenTimestamps sozinho.” Você não precisa. O GitHub App cuida do protocolo de ponta a ponta, e a próxima seção mostra como você verifica o resultado.

Verificando e Apresentando a Prova

A verificação é local e zero-knowledge. Qualquer pessoa pode pegar o arquivo .ots e verificá-lo na blockchain do Bitcoin sem confiar no Timestamp GIT — ou precisar que nossa empresa exista. A prova criptográfica depende inteiramente de SHA-256 e dos dados de blocos do Bitcoin. É isso que “independente de fornecedor” significa na prática: sem formato proprietário, sem lock-in.

Para uso diário, o produto apresenta a mesma evidência em formas mais amigáveis:

  • Página de verificação pública em /verification/{user}/{repo}/{date} — uma verificação passo a passo da cadeia de Merkle em múltiplos níveis. Toda a computação acontece localmente no seu navegador. Ninguém vê o que você verifica.
  • Certificado em PDF para uma data específica (/api/report/{user}/{repo}/{date}), que é o artefato que você entrega ao departamento jurídico.
  • CSV de auditoria do livro-razão completo (/api/audit/{user}/{repo}), útil para uma revisão completa da cadeia de custódia.
  • Badges de README que exibem publicamente o status de verificação. Investidores e adquirentes leem isso como sinais de maturidade em PI. As URLs dos badges e os trechos de markdown vêm de /api/badgeLink/{user}/{repo}.

Uma forma rápida de verificar o status público a partir de um script:

curl -s https://timestampgit.dev/api/statusSummary/acme/payments-service

Repositórios privados anexam um HMAC criptografado à URL, então apenas usuários autorizados podem ver seu status. O HMAC é específico para a instância do servidor.

Para a versão passo a passo deste processo — incluindo como percorrer a cadeia de Merkle você mesmo — consulte Como Verificar o Carimbo de Data/Hora Bitcoin de um Repositório Git.

Opções de Implantação: Gerenciado, Enterprise ZK ou Auto-hospedado

Modo padrão (GitHub App). Instale o app no repositório. Ele lê apenas o hash do commit HEAD e grava as provas em um branch de timestamps ou em um repositório sombra. O modelo de permissões do GitHub significa que precisamos de pelo menos acesso somente leitura ao repositório de código-fonte (não existe permissão apenas para hash de commit), além de acesso leitura-escrita ao repositório de destino.

Modo Enterprise ZK. Uma GitHub Action de 12 linhas roda na sua infraestrutura e envia apenas o hash do commit para a API. Nenhum acesso de leitura ao repositório de código-fonte é necessário, e seu código nunca sai do seu ambiente.

Licença auto-hospedada em Docker. Para máxima segurança e ambientes air-gapped, o Timestamp GIT é distribuído como uma imagem Docker. Uma configuração rápida de Docker Compose se parece com isto:

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

A aplicação fica disponível em http://localhost:8080 após a inicialização, e um assistente de configuração na primeira execução orienta você na conexão do seu GitHub App. Uma licença de demonstração por tempo limitado para avaliação está disponível através do formulário de solicitação na página de Licença Docker. O passo a passo do Docker auto-hospedado cobre a configuração completa se você seguir esse caminho.

Perguntas Frequentes

Um carimbo de data/hora de commit Git ancorado no Bitcoin é realmente admissível em uma disputa de patentes? Ele fornece evidência pronta para tribunal baseada em padrões criptográficos globalmente reconhecidos. A prova mostra que um hash de commit existia em um momento específico de bloco do Bitcoin, o que pode ser usado para estabelecer prior art. A admissibilidade depende da sua jurisdição e do seu advogado, mas a prova criptográfica em si é matematicamente verificável por qualquer pessoa.

O Timestamp GIT vê ou armazena meu código-fonte? Não. O Timestamp GIT processa apenas hashes de commit. No modo padrão, o GitHub App lê o hash do commit HEAD; no modo Enterprise ZK, uma GitHub Action envia apenas o hash da sua infraestrutura, sem acesso de leitura ao repositório de código-fonte. Seu código permanece no seu ambiente.

O que preciso instalar nas máquinas dos meus desenvolvedores? Nada. O Timestamp GIT é um GitHub App gerenciado. Você o instala uma vez no repositório, e cada commit é ancorado automaticamente a cada noite. Não há ferramentas de CLI para sua equipe aprender ou lembrar.

Quanto custa proteger um repositório privado? Repositórios públicos são gratuitos no plano Open Source. Repositórios privados são cobertos pelo Pro Agency a $49/mês, e o Enterprise ZK com GitHub Actions custa $199/mês. Uma licença auto-hospedada em Docker também está disponível para ambientes air-gapped, com uma licença de demonstração por tempo limitado para avaliação.

Conclusão

Uma prova de carimbo de data/hora de commit Git transforma algo que você já faz — commitar código — em prior art que você pode defender. O histórico de commits sozinho não sobreviverá a uma auditoria jurídica, porque é editável e hospedado por outra pessoa. Um hash ancorado no Bitcoin sobreviverá, porque a matemática é pública e o registro é imutável.

O caminho prático é parar de pensar em carimbos de data/hora como uma tarefa manual. Instale o GitHub App uma vez, aponte-o para os repositórios que importam e deixe a ancoragem noturna fazer o trabalho. Consulte o painel de status quando precisar de evidência, incorpore um badge quando quiser mostrar maturidade em PI, e entregue o recibo .ots ao seu advogado no dia em que você realmente precisar dele.

Posts relacionados

EU label: AI-generated content