Sellado temporal en Bitcoin: qué prueba y qué no

Un sello temporal anclado en Bitcoin prueba que un dato concreto existía antes de que se minara un bloque determinado. Fija un límite superior de fecha —no una hora exacta— y detecta cualquier alteración posterior del archivo. No acredita quién creó el contenido, ni quién lo selló, ni qué derechos tiene nadie sobre él. Es un hecho técnico comprobable por terceros, y su valor está justamente en lo estrecho de esa afirmación.

Casi todo el marketing de «certificación blockchain» exagera precisamente en ese punto. Este artículo explica el mecanismo real, con sus reglas de consenso y sus márgenes, para que puedas decidir si te sirve y para que sepas defenderlo si alguien lo cuestiona.

¿Qué es exactamente un sello temporal?

Un sello temporal criptográfico es una afirmación verificable de que un dato existía antes de un instante. La definición canónica está en el RFC 3161, que describe el protocolo clásico de autoridades de sellado: el cliente envía el resumen criptográfico de un dato y la autoridad devuelve un token firmado con la hora.

El elemento que viaja no es el archivo: es su huella. Se calcula con SHA-256, algoritmo especificado en FIPS 180-4, y tiene dos propiedades que hacen posible todo lo demás:

• Determinismo. El mismo archivo produce siempre la misma huella.
• Sensibilidad total. Cambiar un solo bit produce una huella completamente distinta.

Por eso un sello sobre la huella prueba también la integridad: si el archivo que presentas hoy produce la huella sellada, es exactamente el mismo archivo. Si produce otra, ha cambiado, aunque no se aprecie a simple vista.

Nada de esto envía tu documento a ningún sitio. La huella no es reversible: de ella no se puede reconstruir el contenido.

¿Cómo llega una huella a un bloque de Bitcoin?

OpenTimestamps es un formato abierto de sellado en cadena de bloques. El recorrido es este:

1. Se calcula el SHA-256 del archivo local.
2. Esa huella se envía a servidores de calendario públicos, que la agregan junto a miles de otras huellas en un árbol de Merkle.
3. La raíz del árbol —un único valor que resume todo el conjunto— se incorpora a una transacción de Bitcoin.
4. Cuando esa transacción entra en un bloque, la huella queda anclada.
5. El cliente genera un archivo .ots: la ruta completa desde tu huella hasta el bloque, con todos los pasos intermedios necesarios para reconstruir la prueba.

La consecuencia práctica es que el coste de anclar millones de documentos es el de una sola transacción, y que la prueba de cada documento es independiente de la de los demás. Con el archivo original y su .ots, cualquiera reconstruye la cadena sin pedir permiso a nadie.

En Veritas UGC este es el mecanismo de anclaje, y el certificado emitido incluye la altura de bloque real y el enlace de verificación pública, sin cuenta ni registro previo del verificador.

¿Qué fecha fija realmente el bloque?

Aquí es donde la mayoría de explicaciones comerciales miente por omisión. La marca temporal de la cabecera de un bloque no es un reloj de precisión. La escribe quien mina el bloque, dentro de los márgenes que permiten las reglas de consenso.

Las dos reglas relevantes, documentadas en la referencia de la cadena de bloques y en la descripción de la marca temporal de bloque, son:

Regla	Qué impide
La marca debe ser posterior a la mediana de los once bloques anteriores (median time past)	Que un minero fabrique un bloque fechado muy en el pasado
Ningún nodo acepta un bloque con marca superior a dos horas sobre su hora ajustada de red	Que un minero fabrique un bloque fechado muy en el futuro

Esas dos restricciones acotan la manipulación pero no la eliminan al segundo. La forma correcta de expresar lo que prueba el sello es: el dato existía antes de que ese bloque se consolidara, con un margen de horas. Para un litigio sobre quién publicó antes un contenido, o sobre si un documento se alteró después de entregarse, ese margen es irrelevante. Para afirmar «a las 14:32:07» no sirve, y quien lo afirme está sobrevendiendo.

Bitcoin Optech documenta además el vector histórico de manipulación temporal que estas reglas mitigan. Conocer el punto débil de tu propia prueba es lo que te permite defenderla; ignorarlo es lo que la derrumba en la primera objeción técnica.

¿Qué prueba y qué no prueba, en una tabla?

Afirmación	¿La sostiene el sello?
Este archivo existía antes de tal fecha	Sí
Este archivo no ha cambiado desde entonces	Sí
La prueba es verificable sin confiar en el emisor	Sí, con el original y el .ots
Yo soy el autor del contenido	No
Yo fui quien selló el archivo	No, salvo que se añada firma de identidad
El contenido del documento es cierto	No
Tengo derechos de explotación sobre la obra	No
El archivo se creó en la fecha indicada	No: solo que existía antes de ella

Esa última fila merece énfasis. Un sello acota por arriba, nunca por abajo. Puedes sellar hoy una foto de hace diez años; el sello dirá que existía hoy, no que se tomó en 2016.

¿En qué se diferencia de un sello cualificado eIDAS?

Son mecanismos complementarios, no rivales. El Reglamento eIDAS establece en su artículo 41 que un sello electrónico cualificado goza de presunción de exactitud de la fecha y de integridad de los datos, y que se reconoce en todos los Estados miembros. Es una presunción jurídica que descansa sobre un prestador cualificado supervisado.

	Sello cualificado eIDAS	Anclaje en Bitcoin
Base de la confianza	Prestador supervisado y su clave	Coste de reescribir la cadena
Efecto	Presunción legal expresa en la UE	Hecho técnico, valorado como prueba
Si el emisor desaparece	La verificación se complica	La verificación sigue siendo posible
Precisión temporal	Alta, del orden de segundos	Margen de horas
Ámbito	Marco jurídico europeo	Independiente de jurisdicción

La combinación cubre lo que cada uno deja fuera: la presunción legal por un lado, la supervivencia y la independencia por el otro. Cuando el escenario previsible es un procedimiento europeo, el sello cualificado aporta presunción; cuando es una disputa transfronteriza a largo plazo, el anclaje aporta durabilidad.

¿Qué pasa si quien selló desaparece?

Esta es la razón de fondo para elegir un anclaje público. Si el proveedor cierra, cambia de dueño, borra su base de datos o simplemente deja de responder correos, la prueba sobrevive: con el archivo original y el .ots, un cliente de OpenTimestamps de software libre verifica el anclaje contra la cadena de Bitcoin sin intervención de nadie.

Un certificado en PDF, por bien firmado que esté, es una afirmación de un tercero. La verificación independiente es lo que convierte esa afirmación en un hecho comprobable. Si un proveedor de sellado no te entrega el material que permite verificar sin él, lo que estás comprando es su palabra.

Por eso en nuestro centro de transparencia publicamos el estado real de cada marco de cumplimiento en lugar de exhibir insignias, y por eso el certificado de Veritas UGC entrega huella, altura de bloque y enlace de verificación pública en la misma pieza.

¿Dónde se rompe el argumento?

Tres límites que conviene tener presentes antes de apoyar una estrategia entera en el sellado:

• El sello no sabe qué selló. Certifica una huella. Si sellaste el archivo equivocado, o una versión ya alterada, el sello certifica ese error con la misma solidez.
• La cadena de custodia sigue siendo tuya. Si pierdes el archivo original, la prueba deja de servir: sin él no puedes recalcular la huella.
• Sellar no es autenticar identidad. Vincular «quién» requiere una capa adicional: firma con certificado, control de acceso, o registro de la operación con trazabilidad. En nuestros despliegues esa capa se diseña dentro del pilar de Compliance porque afecta a retención, minimización y derechos de acceso.

¿Cuándo compensa sellar?

Compensa cuando el coste de no poder probar algo supera con claridad el coste de sellarlo, que es marginal. Casos habituales:

• Entregas a cliente y versiones aprobadas de un proyecto.
• Piezas de autoría propia antes de publicarse, como detallamos en cómo probar que una foto es tuya.
• Contenido difamatorio o infractor detectado, antes de solicitar su retirada.
• Comunicaciones críticas de un incidente, para que la cronología no dependa de la memoria de nadie.
• Documentación de cumplimiento cuya integridad haya que demostrar en una auditoría posterior.

En cambio no compensa como sustituto de un registro de marca, de un contrato bien redactado o de un control de acceso. Es una capa, no un sistema.

Qué hacer ahora

1. Identifica los tres documentos o piezas cuya pérdida de credibilidad te costaría más caro. Empieza por ahí.
2. Comprueba que conservas los originales íntegros, no solo las versiones exportadas o comprimidas.
3. Exige verificación independiente a cualquier proveedor de sellado: si no puedes comprobar la prueba sin él, no es una prueba, es una promesa.
4. Define quién sella y cuándo dentro de tu proceso, para que no dependa de que alguien se acuerde.
5. Documenta el margen temporal en tus propios procedimientos, para que nadie de tu equipo afirme en un correo más de lo que el mecanismo sostiene.

Si quieres revisar qué parte de tu operación necesita prueba de integridad y qué parte necesita otra cosa, escríbenos desde contacto.