Cómo verificar la marca de tiempo de Bitcoin de un repositorio Git

2026-10-06 timestamp git blockchain proof

Cómo verificar la marca de tiempo Bitcoin de un repositorio Git

Tienes un recibo .ots en tu repositorio. Ahora alguien — un abogado, un auditor, un adquirente haciendo diligencia debida técnica — hace la única pregunta que importa: ¿cómo sabemos que esto es real?

Esa pregunta es el punto central de la técnica anterior criptográfica. Una marca de tiempo que no puedes verificar de forma independiente es solo una afirmación en una base de datos. Una marca de tiempo que cualquiera puede verificar contra la blockchain de Bitcoin es evidencia. Este artículo recorre la ruta de verificación para repositorios anclados por Timestamp GIT, desde la insignia del README hasta la prueba de Merkle.

Por qué la verificación importa para las marcas de tiempo de Git

El historial de Git es sorprendentemente fácil de disputar. Las fechas de commit las establece la máquina que hizo el commit, así que pueden retrodatarse con una sola variable de entorno. El historial alojado vive en servidores que no controlas, y el historial autoalojado vive en una base de datos que alguien con derechos de administrador puede reescribir. En una auditoría legal, ambos se descartan rutinariamente por ser interesados.

El anclaje criptográfico cierra esa brecha — pero solo si la prueba puede ser verificada por un tercero que no confía ni en ti ni en el proveedor. Eso implica dos requisitos:

La verificación no debe requerir confiar en Timestamp GIT. La prueba es una cadena de hashes SHA-256 que termina en un bloque de Bitcoin. Cualquiera puede recorrer esa cadena con herramientas de código abierto.
La verificación no debe requerir exponer tu código fuente. Timestamp GIT opera con un modelo de conocimiento cero: el servicio recibe hashes de commits, nunca contenidos de archivos. No hay nada que inspeccionar salvo hashes — que es exactamente lo que quiere un auditor, ya que significa que la prueba puede compartirse sin compartir el código base.

Debido a ese diseño, la verificación es un ejercicio criptográfico, no una revisión de código. Auditores, la parte contraria o el equipo de ingeniería de una empresa adquirente pueden validar el mismo recibo y llegar a la misma conclusión.

Cómo se ve una prueba de Timestamp GIT

Tras la ejecución de anclaje nocturna, cada repositorio monitorizado obtiene tres artefactos:

Un manifiesto diario (.txt) — la lista de hashes de commits agrupados para ese día, un archivo por repositorio.
Una raíz de Merkle — el único hash SHA-256 calculado a partir de ese manifiesto. Todos los hashes individuales se colapsan en un solo valor.
Un recibo .ots — la prueba de OpenTimestamps que vincula la raíz de Merkle a un bloque de Bitcoin específico.

Estos artefactos se envían de vuelta a tu repositorio en una rama dedicada de marcas de tiempo, o a un repositorio sombra separado si prefieres mantener limpio el repositorio fuente. En cualquier caso, las pruebas se versionan junto al código que atestiguan, pero en su propia referencia — nunca se hace commit de nada en tus ramas de trabajo.

Merece la pena decir dos cosas con claridad:

La prueba no contiene ningún código fuente. Solo hashes de commits y sus reducciones criptográficas.
La prueba no es propietaria. Es un recibo estándar de OpenTimestamps sobre una transacción de Bitcoin, y sigue siendo válido tanto si Timestamp GIT sigue existiendo como si no.

Una vez que el archivo de recibo está en tu repositorio, tienes todo lo necesario para verificar — el resto son herramientas.

Verificación paso a paso con las herramientas de Timestamp GIT

Paso 1 — Localiza la prueba

Abre la rama de marcas de tiempo (o el repositorio sombra) y encuentra el manifiesto de la fecha en cuestión, junto con el archivo .ots correspondiente. Si prefieres no rebuscar entre ramas, la página de estado del repositorio muestra la misma información en el navegador:

https://timestampgit.dev/status/{user}/{repo}

Paso 2 — Lee la página de estado pública

La página de estado es la comprobación rápida más veloz. Muestra:

La longevidad de la prueba y la fecha de anclaje más temprana
La regularidad diaria (un mapa de calor tipo calendario de los días anclados)
El bloque y la transacción de Bitcoin que portan el anclaje
Enlaces de descarga para el CSV de auditoría y el certificado PDF

Para comprobaciones automatizadas, los mismos datos se exponen como JSON:

# Last anchored Bitcoin block
curl -s https://timestampgit.dev/api/statusLast/acme/payments-service

# Total number of stamped commits
curl -s https://timestampgit.dev/api/statusCount/acme/payments-service

# Combined summary (used by the Shields.io badges)
curl -s https://timestampgit.dev/api/statusSummary/acme/payments-service

Paso 3 — Verifica una fecha concreta en el navegador

Para la prueba a nivel de día, usa la página de verificación criptográfica:

https://timestampgit.dev/verification/{user}/{repo}/{date}

Esta página realiza la verificación completa de la cadena de Merkle multinivel localmente en tu navegador. El hash del commit, el manifiesto, la ruta de Merkle y la cabecera del bloque de Bitcoin se comprueban todos en tu máquina — la página no sube lo que estás verificando. Esa propiedad importa cuando el repositorio es privado o está bajo NDA: el auditor puede confirmar la prueba sin que el proveedor se entere de qué fecha le interesaba.

Paso 4 — Obtén el libro de auditoría o el certificado PDF

Los equipos de cumplimiento normalmente necesitan un artefacto que puedan archivar. Ambos están a una petición de distancia:

# Full audit ledger as CSV
curl -fsSL https://timestampgit.dev/api/audit/acme/payments-service -o audit.csv

# PDF certificate for one day
curl -fsSL https://timestampgit.dev/api/report/acme/payments-service/2026-09-14 -o certificate.pdf

Paso 5 — Opcionalmente, incrusta una insignia de verificación

El widget de insignia en /connected/{user}/{repo} te da una vista previa en vivo y un fragmento de Markdown listo para pegar en tu README. Insértalo y cualquiera — un cliente, un inversor, un posible adquirente — puede hacer clic hasta la vista de verificación pública:

<!-- Snippet copied from https://timestampgit.dev/connected/acme/payments-service -->
[![Bitcoin-timestamped](BADGE_IMAGE_URL)](VERIFY_LINK)

Cada paso anterior funciona con el flujo de trabajo gestionado de la GitHub App. Instalas la app una vez, y la verificación es una carga de página o una petición HTTP — sin herramientas de línea de comandos, sin manejo manual de protocolos, nada que mantener en las máquinas de los desarrolladores.

Interpretar los resultados de verificación y casos límite

Una verificación exitosa te dice algo limitado y poderoso: el hash del commit existía en o antes de la marca de tiempo del bloque de Bitcoin referenciado por el recibo, y la prueba de Merkle vincula ese hash específico a ese bloque. Como los bloques de Bitcoin no pueden reescribirse sin rehacer la prueba de trabajo, el límite “en o antes” es absoluto.

Surgen regularmente algunas situaciones:

Sin prueba para una fecha dada. Normalmente significa que no hubo commits ese día — el manifiesto se construye a partir de hashes pendientes, así que un día vacío no produce nada que anclar. Consulta el mapa de calor en la página de estado para confirmarlo.
Confirmación pendiente. El anclaje es un proceso de dos etapas. El worker cron nocturno agrupa hashes, construye el árbol de Merkle y envía la raíz a los calendarios públicos de OpenTimestamps; la confirmación en un bloque de Bitcoin tarda luego unas pocas horas — normalmente alrededor de tres. Una prueba escrita poco después de medianoche puede por tanto no ser definitiva hasta más tarde esa misma mañana.
Repositorios privados. El acceso a las páginas de estado y verificación para repos privados requiere un HMAC cifrado añadido a la URL. El HMAC es específico de la instancia del servidor, así que los enlaces no pueden reutilizarse contra otro despliegue.
Independencia del proveedor. Si prefieres no usar en absoluto el verificador alojado, descarga el archivo .ots y pásalo por las herramientas de código abierto de OpenTimestamps contra la blockchain de Bitcoin tú mismo. Esa es la vía difícil, y es más lenta, pero existe — y su existencia es lo que hace creíble la vía gestionada.

Verificación en entornos empresariales y autoalojados

Modo ZK empresarial. Una GitHub Action de 12 líneas se ejecuta en tu propia infraestructura y solo envía hashes de commits a la API de Timestamp GIT. El servicio nunca tiene acceso de lectura al repositorio fuente; solo necesitas acceso de lectura-escritura al repositorio destino que recibe las pruebas. La verificación no cambia — los mismos archivos .ots, los mismos datos públicos de Bitcoin, las mismas comprobaciones de Merkle en el navegador.

Docker autoalojado. Para entornos con aislamiento de red, Timestamp GIT se distribuye como una imagen Docker que ejecutas tú mismo. Una configuración rápida de Docker Compose tiene este aspecto:

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

La instancia está disponible en http://localhost:8080, y un asistente de configuración en el primer arranque te guía para conectar tu GitHub App y configurar el despliegue. La verificación funciona enteramente dentro de tu red: los archivos .ots, los manifiestos y el verificador local son todo lo que necesitas.

Hay disponible una licencia de demostración por tiempo limitado para evaluación enviando el formulario de solicitud en la página de licencia de Docker con tu nombre, empresa, correo electrónico y teléfono opcional; el archivo de licencia puede descargarse de inmediato.

Automatizar la verificación para equipos de cumplimiento

La verificación manual está bien para una auditoría. El cumplimiento continuo la quiere en un pipeline. La API REST cubre eso:

#!/usr/bin/env bash
set -euo pipefail

REPO="acme/payments-service"
BASE="https://timestampgit.dev/api"

# Merkle chain data for local verification of a specific day
curl -fsSL "$BASE/verify/$REPO/2026-09-14" -o "verify-2026-09-14.json"

# Monthly audit ledger
curl -fsSL "$BASE/audit/$REPO" -o "audit-$REPO.csv"

# PDF certificate per anchored day
curl -fsSL "$BASE/report/$REPO/2026-09-14" -o "certificate-2026-09-14.pdf"

Para paneles de control, consulta periódicamente los endpoints de estado en lugar del payload de verificación completo:

# Feed /api/statusLast and /api/statusCount into your monitoring system
curl -fsSL "$BASE/statusLast/$REPO"
curl -fsSL "$BASE/statusCount/$REPO"

Un patrón útil es tratar un statusLast obsoleto como condición de alerta: si el último bloque anclado no se ha movido en más de un día para un repositorio con commits activos, algo en el pipeline necesita atención. Todo el cálculo de verificación ocurre localmente en el navegador o dentro de tu propio script — ningún payload sensible sale de tu control. Si todavía estás configurando el lado del anclaje de esto, consulta Marca de tiempo Git automatizada: cómo una GitHub App ancla cada commit; este artículo trata deliberadamente sobre lo que ocurre después.

Preguntas frecuentes

¿Necesito ejecutar alguna herramienta de línea de comandos para verificar una prueba de Timestamp GIT? No. Timestamp GIT proporciona una página de verificación web que realiza todas las comprobaciones criptográficas localmente en tu navegador. También puedes descargar el archivo .ots y usar las herramientas estándar de OpenTimestamps si lo prefieres, pero el servicio gestionado no requiere ningún uso de CLI.

¿Puedo verificar una marca de tiempo sin confiar en Timestamp GIT? Sí. La prueba se basa únicamente en hashes SHA-256 y datos de bloques de Bitcoin. Puedes verificar de forma independiente el archivo .ots contra la blockchain de Bitcoin usando herramientas de código abierto de OpenTimestamps, garantizando la independencia del proveedor.

¿Cuánto tarda una marca de tiempo en volverse verificable? Después de que el cron nocturno ancle la raíz de Merkle en una transacción de Bitcoin, normalmente tarda unas 3 horas en confirmarse la transacción en un bloque de Bitcoin. Una vez confirmada, la prueba es inmutable y verificable.

¿Puedo verificar marcas de tiempo de repositorios privados? Sí, pero el acceso a las páginas de estado y verificación para repositorios privados requiere un HMAC cifrado añadido a la URL. Esto garantiza que solo los usuarios autorizados puedan ver los detalles de la prueba.

Conclusión

La verificación es donde una marca de tiempo deja de ser una promesa y se convierte en evidencia. La cadena es corta y comprobable: hash del commit → manifiesto diario → raíz de Merkle → bloque de Bitcoin. Ya sea que lo confirmes en la página de estado, ejecutes la verificación de Merkle en el navegador o saques el libro CSV para una presentación, la conclusión se apoya en las matemáticas de Bitcoin y no en la palabra de nadie — incluida la nuestra.

Instala la GitHub App en un repositorio, deja que la ejecución nocturna haga su trabajo, y luego verifica tú mismo una fecha antes de que alguien te lo pida. Tarda unos minutos y es la diferencia entre “creemos que podemos demostrarlo” y “aquí está la prueba”.

Entradas relacionadas

Cómo verificar la marca de tiempo de Bitcoin de un repositorio Git