Cómo demostrar que tu código existía en una fecha específica (sin revelarlo)

2026-09-08 timestamp git blockchain proof

Cómo demostrar que tu código existía en una fecha concreta (sin revelarlo)

La tarea es fácil de enunciar pero difícil de resolver bien: demostrar que un commit concreto—o un repositorio entero—existía en una fecha determinada, sin publicar tu código fuente ni depender de registros que un tribunal podría descartar por considerarlos interesados. Esta guía explica exactamente cómo hacerlo con Timestamp GIT, una GitHub App gestionada que ancla los hashes de commits de Git a la blockchain de Bitcoin mediante el protocolo OpenTimestamps.

Al terminar, tendrás un sellado de tiempo automatizado y de conocimiento cero para tu historial de Git. Cada commit monitorizado recibe un recibo criptográfico .ots, una página pública de verificación y una vía hacia pruebas de estado de la técnica listas para presentar ante un tribunal—todo sin instalar herramientas de OpenTimestamps ni tocar transacciones de Bitcoin tú mismo.

Requisitos previos

Antes de empezar, asegúrate de tener:

Una cuenta de GitHub.
Un repositorio que quieras sellar temporalmente—público o privado.
Acceso para instalar la GitHub App Timestamp GIT desde timestampgit.dev.
Comodidad básica con git commit y git push. No se requieren conocimientos de criptografía ni de blockchain.
Para el modo Enterprise ZK: un archivo de workflow de GitHub Actions proporcionado por Timestamp GIT, más un repositorio de destino donde se escribirán las pruebas.
Opcional: si necesitas una configuración aislada o autoalojada, una licencia Docker de Timestamp GIT.

Los precios se adaptan al caso de uso: los repositorios públicos pueden usar el plan gratuito, los repositorios privados están cubiertos por Pro Agency a $49/mes, y el modo Enterprise ZK con GitHub Actions comienza en $199/mes.

Paso a paso: Configurar el sellado de tiempo automático

Paso 1: Instalar la GitHub App Timestamp GIT

Ve a timestampgit.dev e instala la GitHub App Timestamp GIT desde GitHub Marketplace.

Los permisos que concedas dependen de tu modo:

Modo estándar: Timestamp GIT necesita acceso de solo lectura al repositorio de origen porque GitHub no ofrece un permiso de “solo hash de commit”. Lee únicamente el hash del commit HEAD, nunca el contenido de los archivos.
Modo Enterprise ZK: Timestamp GIT no necesita ningún acceso de lectura al repositorio de origen. Solo necesitas acceso de escritura a un repositorio de destino separado donde vivirán los archivos de prueba.

En ambos modos, el repositorio de destino recibe una rama dedicada o un repositorio espejo que contiene las pruebas.

Paso 2: Seleccionar los repositorios a monitorizar

Después de la instalación, abre el panel de repositorios en timestampgit.dev/repos. Verás los repositorios que puedes monitorizar.

Selecciona los repositorios de origen que deben sellarse temporalmente de forma automática. Si usas un repositorio espejo separado para las pruebas, elige ese como destino.

Paso 3: Elegir tu modo de despliegue

Timestamp GIT ofrece dos modos:

Modo estándar: La GitHub App detecta nuevos commits automáticamente mediante webhooks y lee solo el hash del commit.
Modo Enterprise ZK: Una breve GitHub Action se ejecuta en tu propia infraestructura y envía solo el hash del commit a la API de Timestamp GIT. Tu código fuente nunca sale de tu entorno.

Para la mayoría de los equipos, el modo estándar es la vía más rápida. Para cumplimiento estricto o entornos de código privado, el modo Enterprise ZK es la opción de conocimiento cero más sólida.

Paso 4: Para el modo Enterprise ZK, añadir el workflow de GitHub Actions

Si eliges el modo Enterprise ZK, Timestamp GIT proporciona un archivo de workflow de 12 líneas. Una versión simplificada tiene este aspecto:

# .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"

El workflow real usa una URL firmada generada en el panel de Timestamp GIT. Esa URL lleva el valor HMAC y el identificador del commit, de modo que la Action nunca maneja código fuente—solo el hash.

Paso 5: Hacer un commit

Ahora crea un commit normal y haz push al repositorio monitorizado:

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

En el modo estándar, la GitHub App detecta el nuevo commit mediante un webhook. En el modo Enterprise ZK, la GitHub Action envía el hash del commit a la API de Timestamp GIT tan pronto como se produce el push.

Paso 6: Esperar al proceso por lotes nocturno

Timestamp GIT no ancla cada commit individualmente en tiempo real. En su lugar, un trabajador cron nocturno se ejecuta a medianoche:

Recopila todos los hashes de commits pendientes.
Los agrupa en archivos de manifiesto diarios.
Construye un árbol de Merkle.
Crea pruebas OpenTimestamps usando calendarios OTS públicos.
Ancla la raíz de Merkle en la blockchain de Bitcoin.

La confirmación de Bitcoin normalmente tarda unas tres horas. Después de eso, la prueba es inmutable—ninguna entidad, incluida Timestamp GIT o tú, puede alterarla.

Paso 7: Recuperar tu prueba

Una vez que termina el proceso nocturno, Timestamp GIT hace push del manifiesto y de los archivos de recibo .ots de vuelta a tu rama de sellos de tiempo dedicada o al repositorio espejo.

También puedes descargar los archivos de prueba directamente desde el panel de Timestamp GIT. Los artefactos principales son:

El archivo de manifiesto diario que contiene los hashes de los commits.
El archivo de recibo .ots para cada lote anclado.
Metadatos de auditoría que muestran la información del bloque y la transacción de Bitcoin.

Cómo confirmar que funcionó (verificación)

La verificación es donde Timestamp GIT convierte un hash de Git en algo que puedes mostrar a un abogado, auditor o tribunal.

Consultar la página de estado del repositorio

Abre https://timestampgit.dev/status/{user}/{repo}. Este panel público muestra:

El último bloque de Bitcoin anclado y los detalles de la transacción.
La fecha de anclaje más antigua del repositorio.
La regularidad del sellado de tiempo diario.
Un mapa de calor de calendario con los commits anclados.
CSV de auditoría y certificado PDF descargables.

Ejecutar la verificación de Merkle en el navegador

Para un día concreto, abre https://timestampgit.dev/verification/{user}/{repo}/{date}. Esta página recorre la verificación de la cadena de Merkle paso a paso.

Todo el cálculo ocurre localmente en tu navegador. Timestamp GIT nunca ve lo que verificas—es un flujo de verificación de conocimiento cero.

Descargar registros formales

Usa el panel o la API para descargar:

Un certificado PDF para una fecha concreta.
Un libro de auditoría completo como CSV.

Estos son útiles para disputas contractuales, diligencia debida de propiedad intelectual y descubrimiento de pruebas legales.

Añadir una insignia de verificación a tu README

Timestamp GIT proporciona fragmentos de insignias Shields.io incrustables desde https://timestampgit.dev/connected/{user}/{repo}. Coloca el Markdown generado en tu README para mostrar públicamente el estado de verificación.

Ten en cuenta que los repositorios privados usan un HMAC cifrado añadido a la URL de la insignia. Solo los usuarios autorizados pueden ver el estado de los repositorios privados.

Verificación independiente

Si alguna vez quieres verificar fuera de la interfaz de Timestamp GIT, puedes descargar el archivo de recibo .ots y ejecutar herramientas estándar de verificación OpenTimestamps contra la blockchain de Bitcoin. La página de verificación en el navegador del producto ya se encarga de esto por ti, pero el recibo sigue siendo verificable de forma independiente para siempre.

Solución de problemas comunes

No se detectan commits

Comprueba que la GitHub App está instalada en el repositorio correcto y tiene los permisos requeridos para tu modo. En la configuración de GitHub, mira las entregas de webhooks para ver si Timestamp GIT recibió el evento de push.

La prueba no aparece después de un día

Recuerda que el anclaje en Bitcoin tarda varias horas—normalmente unas tres horas. Confirma que el trabajo cron nocturno se ejecutó y que la rama de destino recibió archivos nuevos. Si estás en modo estándar, comprueba que el repositorio de destino sea escribible.

La insignia muestra “No verificado”

Si el repositorio es privado, la insignia pública no funcionará a menos que uses la URL firmada con HMAC del widget de insignias. Para repositorios públicos, asegúrate de usar el fragmento exacto generado por Timestamp GIT.

El modo Enterprise ZK no envía hashes

Abre los registros del workflow de GitHub Actions y busca errores. Confirma que:

La URL firmada en el secreto del repositorio sigue siendo válida.
El repositorio de destino es accesible.
El workflow se ejecuta en los eventos de push correctos.

Problemas con la instancia Docker autoalojada

Si ejecutas la imagen Docker, verifica la configuración de Compose y los registros:

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

Comprueba también que el archivo de licencia sea válido y esté montado en la ubicación esperada. La aplicación está disponible en http://localhost:8080 después del arranque.

Preguntas frecuentes

¿Cómo demuestra Timestamp GIT que mi código existía en una fecha sin ver mi código?

Timestamp GIT extrae solo el hash del commit de Git—una huella criptográfica unidireccional—y ancla ese hash en la blockchain de Bitcoin. El código fuente real nunca sale de tu repositorio. Como el hash no puede invertirse para revelar el código, el sello de tiempo demuestra que el hash existía en ese momento, lo que a su vez demuestra que el código existía.

¿Puedo usar Timestamp GIT para repositorios privados?

Sí. Timestamp GIT tiene planes para repositorios privados. En el modo estándar, la GitHub App necesita acceso de lectura al repositorio de origen para detectar los hashes de los commits, pero nunca lee el contenido de los archivos. En el modo Enterprise ZK, una GitHub Action envía solo el hash del commit a la API, por lo que la app nunca tiene acceso al repositorio de origen.

¿Qué pasa si Timestamp GIT cierra? ¿Puedo seguir verificando mis sellos de tiempo?

Tus sellos de tiempo siguen siendo verificables para siempre. Las pruebas se basan en la blockchain de Bitcoin y el protocolo OpenTimestamps, ambos independientes de Timestamp GIT. Puedes descargar los archivos de recibo .ots y verificarlos localmente usando herramientas estándar de OpenTimestamps contra la blockchain de Bitcoin, sin depender de los servidores de Timestamp GIT.

¿El sello de tiempo es legalmente vinculante en un tribunal?

Ningún sello de tiempo puede garantizar un resultado legal concreto. Sin embargo, los sellos de tiempo criptográficos anclados en la blockchain de Bitcoin son cada vez más reconocidos como evidencia sólida de existencia en un momento dado. Proporcionan un registro a prueba de manipulaciones y matemáticamente verificable que puede presentarse en procedimientos legales para respaldar reclamaciones de estado de la técnica o autoría. Debes consultar a un asesor legal sobre la admisibilidad en tu jurisdicción.

Conclusión

Ya has configurado el sellado de tiempo automático y de conocimiento cero para tus commits de Git con Timestamp GIT. En lugar de mantener registros internos frágiles o aprender manualmente un protocolo criptográfico, instalaste una GitHub App una vez, conectaste un repositorio y dejaste que los procesos nocturnos anclaran los hashes de los commits en Bitcoin.

El resultado es una prueba inmutable de estado de la técnica, independiente de cualquier proveedor, generada sin revelar el código fuente. Empieza con el plan gratuito para repositorios públicos, o explora la opción autoalojada con Docker si necesitas infraestructura aislada.

Para profundizar más, consulta las publicaciones relacionadas a continuación.

Publicaciones relacionadas

Cómo demostrar que tu código existía en una fecha específica (sin revelarlo)