Alternativas a OpenTimestamps: Sellado de tiempo gestionado para Git

Ya has aceptado la premisa: quieres que tus commits de Git estén anclados en Bitcoin, de modo que un estado específico de tu repositorio demuestre de forma verificable que existió en una fecha concreta. Esa parte no está a debate.

La verdadera decisión de compra es quién ejecuta el pipeline.

El protocolo OpenTimestamps es el estándar sobre el que se construyen la mayoría de estos sistemas, y es genuinamente bueno: abierto, neutral respecto al proveedor, verificable contra Bitcoin mismo. Pero un protocolo es un kit de herramientas, no un producto. En algún punto entre “el protocolo existe” y “mis commits se sellan cada noche, y mi responsable de cumplimiento puede descargar un certificado en PDF”, tiene que ocurrir mucho trabajo. Este artículo compara las opciones realistas para el sellado de tiempo de Git en 2026, para que puedas decidir dónde debe vivir ese trabajo: en la carga de tu equipo, o detrás de una GitHub App que instalas una vez.

La decisión de compra: ¿por qué mirar más allá de OpenTimestamps en bruto?

OpenTimestamps resuelve el problema criptográfico difícil: convierte un hash en una prueba de existencia anclada en la blockchain de Bitcoin, usando servidores de calendario públicos para que no pagues una comisión de transacción por cada sello de tiempo.

Lo que no resuelve:

• Detección de commits. El protocolo no tiene ni idea de qué es Git. Alguien tiene que decidir qué commits se sellan.
• Economía del agrupamiento por lotes. Sellar una prueba por commit es un desperdicio. Las configuraciones reales agrupan los hashes a diario en un árbol de Merkle y anclan solo la raíz.
• Almacenamiento de claves y pruebas. Los recibos .ots son pequeños, pero deben vivir en algún lugar duradero, en algún lugar donde un abogado pueda encontrarlos dentro de tres años.
• Experiencia de verificación. “Descarga un archivo y compruébalo contra Bitcoin” no es un flujo de trabajo que la mayoría de los equipos de cumplimiento vaya a adoptar.
• Operación continua. Rarezas de los servidores de calendario, rutas de actualización y la pregunta de quién está de guardia cuando el trabajo nocturno deja de producir pruebas en silencio.

Ese es el coste oculto del DIY: no la criptografía, sino la fontanería que la rodea. La elección es si seguir operando un protocolo o adoptar un servicio que lo automatice de principio a fin. Timestamp GIT es la opción gestionada en esta comparación: oculta el protocolo detrás de una GitHub App y un trabajo nocturno, de modo que ningún desarrollador toca jamás un comando de sellado de tiempo.

Una frase de honestidad antes de la comparación: sí, puedes lograr todo esto a mano con el protocolo abierto y un trabajo cron. Este artículo compara ese camino con las alternativas; no te guía paso a paso para construirlo.

El panorama: ¿qué opciones existen para el sellado de tiempo de Git?

Hay cuatro formas de solución que encontrarás.

1. El enfoque de OpenTimestamps en bruto. Instalas las herramientas del cliente, escribes tus propios scripts de recolección de commits, gestionas la interacción con el calendario, almacenas las pruebas tú mismo y verificas manualmente contra Bitcoin. Control máximo, superficie máxima. No es nativo de Git y no viene con un panel, una insignia ni un informe de auditoría.

2. Plataformas de sellado de tiempo en blockchain con API. Te dan un endpoint HTTP que acepta un hash y devuelve un recibo. Mejor que las herramientas en bruto, pero son genéricas: sellan cualquier cosa, así que la integración con Git es tu problema. Sigues teniendo que construir la lógica de vigilancia de commits, el agrupamiento por lotes y la capa de almacenamiento.

3. Servicios gestionados de sellado de tiempo para Git. Esta es la categoría que ocupa Timestamp GIT: instalas una GitHub App, seleccionas repositorios y cada commit se recopila automáticamente. Cada noche, un worker agrupa los hashes de commits del día, construye un árbol de Merkle y ancla la raíz en Bitcoin a través de calendarios públicos de OpenTimestamps. Las pruebas vuelven a tu propio repositorio.

4. Despliegues autoalojados con licencia. La comodidad gestionada no tiene por qué significar los servidores de otro. Timestamp GIT se distribuye como una imagen de Docker que puedes ejecutar tú mismo: la opción relevante para entornos aislados y políticas de seguridad estrictas.

Criterios de selección: qué deben evaluar los desarrolladores y los equipos de cumplimiento

Cuando comparas opciones, el protocolo subyacente importa menos que el modelo operativo que hay por encima. Seis criterios concentran la mayor parte de la decisión:

• Esfuerzo de configuración. Instalación de la GitHub App con un clic frente a instalar herramientas, escribir scripts y conectar un planificador.
• Nivel de automatización. ¿El sistema detecta nuevos commits por sí solo, o tiene que acordarse un humano?
• Seguridad y privacidad. ¿Puede el servicio hacer su trabajo sin leer tu código fuente? ¿Existe un modo en el que tu código nunca salga de tu infraestructura?
• Superficie de integración. Integración con el alojamiento de Git, insignias en el README, endpoints REST, registros de auditoría CSV, certificados en PDF.
• Modelo de costes. Nivel gratuito para repositorios públicos, precios transparentes por nivel para los privados y una licencia autoalojada cuando necesitas soberanía.
• Verificabilidad y dependencia del proveedor. ¿Puede un tercero verificar tu prueba usando herramientas estándar y datos de bloques de Bitcoin, sin que tu proveedor intervenga?

Ese último criterio es el que los equipos subestiman. Un sello de tiempo que no puedes verificar de forma independiente no es más que una fila en una base de datos con buen marketing.

Comparación lado a lado: protocolo en bruto vs. servicios gestionados

Fíjate en el patrón de la columna central: una API elimina el trabajo criptográfico, pero deja el trabajo de Git. Ahí es a menudo donde se estancan los proyectos DIY: no porque el anclaje sea difícil, sino porque la recolección de commits, el agrupamiento y la entrega son lo bastante aburridos como para quedar perpetuamente postergados.

Veredicto: ¿quién debería elegir qué opción?

Desarrolladores individuales y mantenedores de código abierto. Si disfrutas de la fontanería y tus repositorios son públicos de todos modos, el protocolo en bruto es defendible. Pero el nivel gratuito de Timestamp GIT cubre los repositorios públicos, así que la pregunta honesta es si tu tiempo se aprovecha mejor en tu proyecto que en mantener un pipeline de pruebas. Como mínimo, elimina el modo de fallo del “ya lo automatizaré bien el mes que viene”.

Startups y agencias. Toma la ruta gestionada. Los argumentos de técnica anterior no se preocupan de que podrías haber sellado esos commits: se preocupan de que lo hiciste, de forma consistente, durante los meses previos a la disputa. La consistencia es una característica del producto, y la automatización nocturna la entrega mucho mejor que las buenas intenciones. Si estás demostrando fechas de entrega durante una disputa de pago, consulta Proteger los entregables de código de una agencia con prueba en blockchain.

Empresas con políticas de seguridad estrictas. El Modo Estándar más la ruta Enterprise ZK, o la licencia autoalojada de Docker, te dan el control que necesitas sin reconstruir el protocolo tú mismo. El modo Enterprise ZK es al que hay que recurrir cuando el repositorio de origen no debe ser legible por el servicio: una GitHub Action envía el hash del commit desde tu propia infraestructura. Si tu preocupación es la exposición de patentes más que los permisos del repositorio, Prueba de sello de tiempo de commits de Git para disputas de patentes cubre ese escenario.

La versión corta: Timestamp GIT no es meramente una alternativa a ejecutar el protocolo: es la versión del protocolo que no tienes que operar.

Cómo funciona Timestamp GIT como alternativa gestionada

Este es todo el flujo de trabajo de cara al desarrollador.

1. Instala la GitHub App una vez. Nada que instalar en las máquinas de los desarrolladores. La app lee solo el hash del commit HEAD de los repositorios monitorizados; tu código fuente nunca se lee, copia ni almacena. En el Modo Estándar, la app requiere al menos acceso de solo lectura al repositorio de origen (no existe un permiso de “solo hash” en el modelo de GitHub) y acceso de lectura y escritura al repositorio de destino, donde se escriben las pruebas.

2. Los commits se recopilan automáticamente. O bien la GitHub App detecta nuevos commits mediante webhooks, o bien —en el Modo ZK Enterprise— una GitHub Action de 12 líneas envía solo el hash del commit a la API de Timestamp GIT. En el Modo ZK no se requiere acceso de lectura al repositorio de origen, pero sí instalas la Action. Los hashes pendientes se quedan en un almacén clave-valor en memoria, esperando el lote.

3. Un worker cron de medianoche ancla el lote. Cada noche, el worker agrupa todos los hashes pendientes, construye archivos de manifiesto .txt por repositorio, arma un árbol de Merkle, crea pruebas de OpenTimestamps usando calendarios públicos de OTS y ancla la raíz de Merkle en la blockchain de Bitcoin. La confirmación de Bitcoin suele tardar unas tres horas, así que las pruebas aparecen unas horas después de que se ejecute el lote.

4. Las pruebas se entregan en tu repositorio. El manifiesto y los archivos de recibo .ots se envían de vuelta a una rama de sellos de tiempo dedicada o a un repositorio en la sombra. A partir de ese momento, el sello de tiempo es inmutable: ninguna entidad, incluido Timestamp GIT, puede alterarlo ni falsificarlo.

5. Verificas y publicas. Las insignias insertables en el README muestran el estado de verificación y enlazan a la página de verificación pública. El panel de estado del repositorio expone la longevidad de las pruebas, la fecha de anclaje más temprana, la regularidad diaria, los datos de bloques y transacciones de Bitcoin, un mapa de calor del calendario y registros de auditoría CSV y certificados en PDF descargables. La verificación en sí se ejecuta localmente en el navegador contra la cadena de Merkle: ningún cálculo de nuestro lado, nadie ve lo que verificas. Si quieres los mecanismos en detalle, lee Cómo verificar el sello de tiempo en Bitcoin de un repositorio de Git.

Para la automatización más allá del panel, hay endpoints públicos:

curl https://timestampgit.dev/api/statusSummary/your-org/your-repo
curl https://timestampgit.dev/api/statusLast/your-org/your-repo
curl -O https://timestampgit.dev/api/audit/your-org/your-repo

Los repositorios privados añaden a sus URL un HMAC cifrado, específico de la instancia del servidor, de modo que solo los usuarios autorizados pueden leer su estado.

La opción autoalojada

Para máxima seguridad y entornos aislados, Timestamp GIT está disponible como imagen de Docker. 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 aplicación está disponible en http://localhost:8080. En el primer arranque, un asistente de configuración te guía para conectar tu GitHub App y configurar la instancia. Hay disponible una licencia de demostración por tiempo limitado enviando el formulario de solicitud en la página de Licencia de Docker con tu nombre, empresa, correo electrónico y número de teléfono opcional; después se puede descargar el archivo de licencia.

Preguntas frecuentes

¿Necesito ejecutar algún comando de OpenTimestamps?

No. Timestamp GIT es un servicio gestionado. Una vez que instalas la GitHub App, detecta los commits automáticamente y los ancla en Bitcoin cada noche. Nunca necesitas ejecutar herramientas de línea de comandos ni gestionar el protocolo tú mismo.

¿Puedo verificar las pruebas sin Timestamp GIT?

Sí. Los archivos de recibo .ots y las pruebas de Merkle se basan en estándares abiertos. Puedes verificarlos de forma independiente usando herramientas estándar de verificación de OpenTimestamps contra la blockchain de Bitcoin, o usar la verificación local basada en navegador de Timestamp GIT, que realiza todos los cálculos en el lado del cliente.

¿Qué pasa si Timestamp GIT cierra?

Tus pruebas están ancladas en la blockchain de Bitcoin y son independientes del proveedor. Los archivos .ots y las pruebas de Merkle se pueden verificar sin conexión usando herramientas de código abierto. Timestamp GIT no te ata: la prueba criptográfica se apoya únicamente en SHA-256 y en los datos de bloques de Bitcoin.

¿Se expone alguna vez mi código fuente?

No. Timestamp GIT opera bajo un principio de conocimiento cero. En el Modo Estándar, la GitHub App lee solo el hash del commit, no el código fuente. En el Modo ZK Enterprise, una GitHub Action envía solo el hash del commit desde tu infraestructura, así que tu código nunca sale de tu entorno.

Conclusión

Todas las opciones de esta comparación terminan en el mismo lugar: un hash SHA-256 dentro de un bloque de Bitcoin. Lo que difiere es cuánta ingeniería, disciplina operativa y memoria institucional tienes que aportar para llegar hasta ahí, y si el resultado es algo que un equipo de cumplimiento pueda entregar de verdad a un abogado.

Si quieres las garantías criptográficas sin convertirte en el mantenedor de un pipeline de sellado de tiempo, instala la GitHub App una vez y deja que el worker nocturno haga el resto. Empieza en el nivel gratuito con un repositorio público para ver cómo llegan las pruebas, y luego pasa los repositorios privados a Pro Agency cuando estés listo. Tus commits ya tienen hashes; bien podrían tener testigos.

Entradas relacionadas

• Proteger los entregables de código de una agencia con prueba en blockchain
• Prueba de sello de tiempo de commits de Git para disputas de patentes
• Cómo verificar el sello de tiempo en Bitcoin de un repositorio de Git