Compruébalo tú.

Qué se comprueba

Los hashes SHA-256 de los documentos que el proyecto se compromete a no cambiar se publican en un repositorio público que solo contiene hashes: github.com/MontanaMiramar/rall-attestations. Cada archivo se sella con OpenTimestamps, que lo ancla en un bloque de Bitcoin. Así cualquiera puede comprobar que ese archivo exacto existía como muy tarde en la fecha de ese bloque.

Preparación, una sola vez

Necesitas Linux o macOS con git y Python 3. En Windows, usa WSL: en nuestra prueba (con Python 3.14), el cliente de OpenTimestamps no funcionó en Windows nativo.

git clone -c core.autocrlf=false https://github.com/MontanaMiramar/rall-attestations.git
cd rall-attestations
python3 -m venv ots-venv
./ots-venv/bin/pip install opentimestamps-client==0.7.2
./ots-venv/bin/ots --version        # v0.7.2

• -c core.autocrlf=false mantiene cada archivo byte a byte tal como se publicó. Sin esa opción, Git en Windows puede cambiar los finales de línea, y los hashes no coincidirán.
• En Debian o Ubuntu, si python3 -m venv falla, instala antes el paquete que nombra su mensaje de error (en Ubuntu 24.04, python3.12-venv).
• En macOS, si no tienes sha256sum, shasum -a 256 hace lo mismo.

Hoy: los 13 pre-registros

Antes de que empiece la Fase 2 se sellaron 13 archivos internos; el .txt de abajo da sus nombres. El repositorio guarda sus hashes, no su contenido, en la carpeta preregistros/:

• 2026-10-26-preregistros.sha256 — los 13 hashes, uno por línea, en formato sha256sum.
• 2026-10-26-preregistros.txt — la lista de los 13, con la hora de sellado que declara el servidor para cada uno, y qué demuestra este anclaje y qué no.
• Cada uno con su prueba de OpenTimestamps (.ots), ya completa.

1. El archivo es el que se selló

sha256sum preregistros/2026-10-26-preregistros.sha256
./ots-venv/bin/ots info preregistros/2026-10-26-preregistros.sha256.ots | grep 'File sha256 hash'

Las dos líneas tienen que mostrar el mismo hash:

2. En qué bloques de Bitcoin está el sello

./ots-venv/bin/ots --no-bitcoin verify preregistros/2026-10-26-preregistros.sha256.ots

--no-bitcoin va antes de verify. El cliente no consulta ningún nodo de Bitcoin; por cada sello imprime un bloque y el merkle root que ese bloque tiene que tener:

To verify manually, check that Bitcoin block 973276 has merkleroot ca070bc7d92dd41e8814b1805cac6f3ac84d86039a5d300dff5d4cc50a560fb4
To verify manually, check that Bitcoin block 973294 has merkleroot d6d7ebc9e32fbb64c165e2975e85db83c08c9fba0fc643fef6f582d795b956b6
To verify manually, check that Bitcoin block 973322 has merkleroot e3d255408dbcaa854893c843784edbc0058f73113f2ce099e6fd593610e90ff5
To verify manually, check that Bitcoin block 973423 has merkleroot 585a9f6411812ce9ba12d3d3c52d2184f9f5d380ee36e83c808db96f01385a2c

3. Compáralo con un explorador público de bloques

Abre el bloque por su altura, por ejemplo mempool.space/block/973276 o blockstream.info/block-height/973276. Los dos ocultan el campo Merkle root (en mempool.space en español, «Raíz de Merkle») hasta que pulsas Detalles. Compáralo tal cual lo imprime el cliente, carácter por carácter. No hay que invertir ni convertir nada. Basta con un bloque; dos exploradores son mejor que uno. Los exploradores pueden mostrar la hora del bloque en tu zona horaria; las de abajo están en UTC.

Cuatro servidores de calendario distintos — dos de ellos bajo opentimestamps.org — sellaron el mismo hash, cada uno en su propio bloque; ots info muestra cuáles. Resultado: estos 13 archivos, con exactamente estos hashes, existían como muy tarde el 2026-10-26 a las 19:16:23 UTC. Los mismos tres pasos sirven para 2026-10-26-preregistros.txt y su .ots. Su hash es distinto (742b76f6…): lo que comprueba el paso 1 es que sus dos líneas coincidan entre sí, no que coincidan con el hash de arriba.

Qué no demuestra: qué dicen los 13 archivos (solo sus hashes son públicos; si llega a publicarse cada uno, su contenido se podrá comprobar entonces con sha256sum -c), las horas de sellado anteriores que figuran en el .txt (las declara el reloj del servidor), ni que no existieran antes versiones distintas. La propia lista marca cuatro archivos como «declarado post-hoc» y uno como «anotado en el registro retroactivamente»; son las etiquetas del propio servidor, tal como figuran en el .txt. Hoy, sha256sum -c sobre los pre-registros responde que no puede leer los 13 archivos: es lo esperado, porque no están publicados.

Desde el 2026-11-10: la metodología congelada

El 10 de noviembre la metodología se congela y se publica byte a byte en el mismo repositorio, en la carpeta methodology/, con su hash y sus sellos:

• METODOLOGIA_SOMBRA_v<versión>.md — el propio archivo.
• METODOLOGIA_SOMBRA_v<versión>.md.sha256 — una sola línea: el SHA-256 en hexadecimal minúscula, dos espacios, el nombre del archivo y un salto de línea.
• .md.ots y .md.sha256.ots — sus pruebas de OpenTimestamps.

La versión exacta, el nombre del archivo y el commit se publicarán ese día aquí y en la página del laboratorio. Después:

cd methodology
sha256sum -c METODOLOGIA_SOMBRA_v<versión>.md.sha256       # → METODOLOGIA_SOMBRA_v<versión>.md: OK
cd ..
./ots-venv/bin/ots --no-bitcoin verify methodology/METODOLOGIA_SOMBRA_v<versión>.md.ots

y se comparan los bloques que imprima, como en el paso 3. Descarga el archivo en crudo (con git clone, o desde raw.githubusercontent.com): copiar el texto desde la vista web de GitHub puede cambiar sus bytes y, con ellos, el hash.

Desde el 2026-11-11: los anclajes diarios

Un archivo por día UTC, anchors/AAAA-MM-DD.txt, con su prueba anchors/AAAA-MM-DD.txt.ots. Los archivos solo se añaden; un día ya publicado no se reescribe. El primero es anchors/2026-11-10.txt, el día del congelado; después, uno por cada día de observación, hasta el 2026-12-11. Cada uno tiene seis líneas:

date_utc: AAAA-MM-DD
anchored_at_utc: AAAA-MM-DDTHH:MM:SSZ
paper_log_chain_head_sha256: <hex64>
paper_log_lines: <entero>
paper_log_file_sha256: <hex64>
methodology_sha256: <hex64>

• paper_log_chain_head_sha256 es el hash de la última línea del registro interno de predicciones. Cada línea de ese registro incluye el hash de la anterior, así que este valor compromete todo el historial hasta ese momento.
• methodology_sha256 tiene que coincidir con el hash de la metodología congelada.

Se comprueban con los mismos tres pasos. En las primeras horas tras un sellado, su .ots puede estar todavía pendiente; en ese caso, ejecuta antes ./ots-venv/bin/ots upgrade anchors/AAAA-MM-DD.txt.ots.

Otras formas de comprobar los sellos

Con tu propio nodo de Bitcoin — la más independiente

./ots-venv/bin/ots verify preregistros/2026-10-26-preregistros.sha256.ots

Necesita un Bitcoin Core sincronizado en la misma máquina, accesible por RPC. Elimina la necesidad de fiarse de cualquier explorador. Sin nodo, el comando se detiene con Could not connect to Bitcoin node.

El verificador web de opentimestamps.org

Se sube el archivo y su .ots. Es cómodo, pero implica fiarse de ese servicio.

No hemos probado nosotros ninguna de estas dos formas; lo explicamos al final de esta página.

Lo que no se puede verificar de forma independiente

Una página de verificación que no dice qué no se puede verificar no lo es. Nada de lo que sigue se puede comprobar desde fuera:

• Que el sistema siguiera de verdad la metodología. El hash prueba que el texto no cambió, no que el código lo aplicara tal cual. Eso solo lo puede juzgar alguien que lea el texto, el código y los datos, si se publican.
• El contenido del registro interno de predicciones. Los anclajes diarios prueban que una cadena de hashes existía en cada fecha, no qué contenía. Las predicciones, su orden y sus firmas solo se podrán comprobar si se publica el registro; entonces se podrá verificar todo hacia atrás, recalculando la cadena.
• El contenido de los 13 pre-registros, mientras no se publiquen. Hoy solo son públicos sus hashes: existían como muy tarde en una fecha determinada, pero no se puede comprobar qué decían.
• Cualquier fecha anterior al primer anclaje. Las horas de sellado de los pre-registros (del 13 al 26 de octubre) y cualquier hora escrita dentro de un archivo, como anchored_at_utc, las pone el reloj del servidor. Lo demostrable es la cota superior que da el bloque de Bitcoin.
• La hora exacta. OpenTimestamps da una cota superior — la hora del bloque —, no el momento en que se escribió un archivo.
• Que no existieran versiones anteriores distintas. Un anclaje prueba que esta versión existía, no que no hubiera otras antes.
• La protección de la rama principal en GitHub (sin force push ni borrado) no se puede comprobar desde fuera, y el propietario del repositorio podría desactivarla. La integridad del historial no descansa en GitHub sino en las pruebas .ots: un archivo alterado no coincidiría con su sello.
• Los exploradores de bloques. Comprobar sin nodo depende de exploradores de terceros para el merkle root de cada bloque. Usar dos exploradores independientes reduce esa confianza; solo un nodo propio la elimina.

Qué probamos

El 2026-10-29 se ejecutaron los comandos de las comprobaciones de hoy como lo haría un tercero: un clon nuevo desde la URL pública, un contenedor Linux limpio (Python 3.12, opentimestamps-client 0.7.2), y el merkle root de cada bloque comparado con mempool.space y con blockstream.info, por sus APIs (todos los bloques) y, para el bloque 973276, en sus páginas web. Todos coincidieron tal cual se imprimen. El formato de sha256sum -c se comprobó con un archivo de prueba.

Sin probar: Windows a través de WSL, de principio a fin — el camino que esta página recomienda a quien usa Windows (en Windows nativo solo probamos el clon y el hash); la vía con nodo propio; el verificador web, y macOS. La metodología y los anclajes diarios todavía no se pueden probar: existirán desde el 10 y el 11 de noviembre.

Contacto

Si algún paso no funciona tal como está escrito, escríbenos: roderickchicas@gmail.com