Nota técnica

Cómo se verifica, y cuánto vale cada prueba

Este documento describe todos los mecanismos empleados en el sitio, para que quien quiera comprobar lo que se afirma pueda hacerlo sin fiarse de nosotros en ningún punto. Y dice, de cada mecanismo, qué acredita exactamente y qué no. Una prueba exagerada es peor que ninguna prueba, porque la exageración acaba siendo la noticia.

1. El texto sellado

El texto canónico del requerimiento es un fichero de texto plano en UTF-8, letter-en.txt, sin marcado, sin metadatos y sin caracteres invisibles. El texto plano se usa deliberadamente: un PDF o un fichero de procesador de textos arrastra estado oculto que cambia entre guardados, de modo que su hash cambiaría sin que cambiara el texto visible, y el sello no probaría nada.

Su resumen SHA-256 es:

2f76219c88e203ede2693d279a24792239a33981fb2e593512bf435824c82c02

El texto español es un fichero aparte con su propio resumen, 3afc9553b5d814fc0051df237f4abc069279bf75dbe91621e8101fe461ea0a60, sellado de forma independiente y etiquetado en todo momento como traducción de referencia.

2. El anclaje del sello en Bitcoin

Un hash publicado en nuestro propio sitio no prueba nada por sí solo: el sitio lo controlamos nosotros, así que podríamos publicar cualquier hash en cualquier momento y afirmar que ya estaba antes. El anclaje es lo que nos saca a nosotros de la cadena de confianza.

El resumen se envió a los calendarios de OpenTimestamps a.pool.opentimestamps.org, b.pool.opentimestamps.org, a.pool.eternitywall.com y ots.btc.catallaxy.com, que agregan los envíos en un árbol de Merkle y comprometen su raíz en una transacción de Bitcoin. El recibo resultante se publica en letter-en.txt.ots, y el español en letter-es.txt.ots.

Para verificarlo de forma independiente, sin visitar este sitio salvo para descargar los dos ficheros: 

pip install opentimestamps-client

curl -O https://restore.vedicvault.org/letter/letter-en.txt
curl -O https://restore.vedicvault.org/letter/letter-en.txt.ots

sha256sum letter-en.txt          # debe coincidir con el resumen de arriba
ots verify letter-en.txt.ots     # confirma la atestación en Bitcoin

Qué acredita. Que un fichero con exactamente este contenido existía a más tardar en el bloque en que se minó el compromiso. Fabricar una fecha anterior falsa exigiría reescribir la historia de Bitcoin.

Qué no acredita. La autoría. Un sello de tiempo dice cuándo, nunca quién. Cualquiera podría haber sellado este texto. Aquí la atribución descansa en la prueba ordinaria de la publicación, no en la criptografía, y no afirmamos nada más fuerte.

Sobre la latencia. Un recibo de OpenTimestamps se emite de inmediato, pero se completa como atestación de Bitcoin cuando se mina el compromiso del calendario, normalmente en unas horas. Ejecutar ots upgrade antes de verificar descarga la ruta ya completada.

3. Almacenamiento permanente

El texto se almacena además en Arweave, una red sin propietario y sin operación de borrado, para que el documento sobreviva a la pérdida de este dominio, de este alojamiento o de nosotros. Subido el 3 de septiembre de 2026. Cada fichero puede descargarse directamente y comprobarse su SHA-256 contra el hash anclado en el bloque 965223 de Bitcoin — las dos pruebas son independientes y ninguna depende de nosotros.

Arweave aporta durabilidad, no integridad. La integridad la aporta el hash. Son dos propiedades distintas y se declaran por separado.

4. Integridad de las firmas

Enviar el formulario escribe un registro pendiente y remite un testigo de un solo uso a la dirección indicada. El registro pasa a activo únicamente cuando se presenta ese testigo. Los registros pendientes no se cuentan nunca, no se muestran nunca, y se eliminan a los treinta días.

Esta doble confirmación defiende de los dos ataques que de verdad importan a un registro de esta clase. El primero es la suplantación: añadir el nombre de un devoto conocido sin que lo sepa, que fracasa porque la confirmación va a una dirección que el atacante no controla. El segundo es el inflado: fabricar miles de firmas para que la lista parezca mayor, que fracasa porque cada una exige un buzón distinto y en funcionamiento.

La dirección de correo es la clave única del registro. La misma dirección no puede aparecer dos veces, se haya enviado desde la página en el idioma que sea: las dos páginas son dos fachadas sobre un mismo sistema, no dos sistemas.

Los envíos del formulario los filtra además Cloudflare Turnstile, una comprobación que no rastrea entre sitios. Puede instalar una cookie propia mientras funciona, y carga solo en las dos páginas que llevan el formulario.

Las entradas del grupo de discípulos iniciados por Śrīla Prabhupāda las revisa una persona, y el año y lugar de iniciación indicados se publican junto al nombre. Esa publicación es la verificación: una afirmación falsa de iniciación, con año y lugar declarados, resulta visible para todos los que estuvieron presentes, en una comunidad donde semejante afirmación no sobrevive una semana. Ningún mecanismo criptográfico lograría esto, y no se pretende ninguno.

5. Por qué el registro deliberadamente no se sella

El registro de firmas se guarda en una base de datos ordinaria y modificable. No se resume, no se ancla, y no se escribe en ningún soporte permanente. Es una decisión de diseño, no un descuido.

Una lista inalterable de nombres es una trampa. Un devoto que firme hoy y reciba presiones dentro de seis meses tiene que poder desaparecer de ella por completo, y un registro permanente lo haría imposible. La permanencia se aplica al texto, que necesita protección, y se retira de la lista de personas, que necesitan protección frente a la permanencia.

El coste de esta decisión es que no podemos demostrar criptográficamente que el registro no se ha editado. Asumimos ese coste, lo decimos aquí en vez de dejar que se descubra como objeción, y ofrecemos a cambio las compensaciones ordinarias: el registro se publica de forma continua en formato legible por máquina en /api/register, y cualquiera puede archivarlo en cualquier momento a través de un tercero como Internet Archive, produciendo una constancia externa que nosotros no podemos alterar.

6. Prueba de la entrega

Cada destinatario del requerimiento recibe un mensaje dirigido individualmente. No se usa envío masivo, ni lista con copia oculta, en ninguna fase. Esto importa como prueba: un mensaje dirigido a una persona es prueba sobre esa persona, mientras que una copia oculta solo prueba que existía una lista.

De cada entrega se conservan tres artefactos.

El acta. Para los destinatarios principales, el mensaje lo procesa además un servicio de certificación independiente, que emite un PDF firmado acreditando el contenido, el destinatario y el momento de la entrega. Es el artefacto que puede valorar un lector no técnico, y lo emite una empresa sin relación alguna con nosotros.

El fichero del mensaje. Se conserva el .eml original con sus cabeceras intactas, incluidos el Message-ID y la DKIM-Signature añadida por el proveedor de envío. DKIM firma el cuerpo y un conjunto de cabeceras con una clave privada cuya mitad pública está publicada en el DNS del proveedor. Cualquiera puede obtener esa clave y confirmar que el contenido, el remitente, el destinatario y la fecha no se han alterado desde el envío. Es el artefacto más sólido de los tres, porque no depende ni de nosotros ni de la empresa certificadora.

El resumen. El SHA-256 del fichero del mensaje se anota en el registro en el momento del envío, de modo que el fichero no pueda sustituirse después.

Cuando la dirección de un destinatario ya está publicada por la propia organización, se publica el .eml completo para que cualquiera pueda validar su firma DKIM. Cuando la dirección no es pública, se enmascara — y enmascararla rompe necesariamente la validación DKIM, así que para esos destinatarios se publican el acta y el resumen y el fichero sin enmascarar se facilita a quien lo pida. Preferimos explicar esta asimetría antes que publicar una dirección privada o un fichero no verificable.

7. Qué acredita el registro, con precisión

Acredita que un documento con una forma concreta existía en una fecha concreta; que se dirigió a una persona identificada, a una dirección que esa persona usa; que fue aceptado para su entrega por el sistema de correo receptor; y si se recibió respuesta dentro del plazo indicado de antemano.

No acredita que el destinatario abriera el mensaje, ni que lo leyera, ni que lo entendiera. Ningún sistema de correo puede acreditar eso, ni siquiera los acuses de lectura, y en ninguna parte de este sitio se afirma lo contrario. Declaramos el límite nosotros mismos porque un registro que se excede en lo que afirma invita a que se descarte entero por culpa de esa única exageración.

8. Lo que dirá un adversario, y la respuesta

«Cambiasteis el texto después de que la gente firmara.» El hash está anclado en Bitcoin y el anclaje es anterior a las firmas. Cualquier cambio en cualquier carácter rompe la verificación, que cualquiera puede ejecutar en cuatro órdenes.

«Os habéis inventado las firmas.» Cada una exigió un buzón en funcionamiento y un clic de confirmación. Los nombres del grupo de iniciados llevan año y lugar de iniciación y puede comprobarlos quien estuvo allí.

«Añadisteis nombres a la lista de invitados a posteriori.» Cada fila se publica el mismo día del envío, no después, y el registro puede archivarlo públicamente un tercero en cualquier momento.

«En realidad nunca lo enviasteis.» La firma DKIM del fichero conservado la produce el proveedor de envío, no nosotros, y puede validarse contra la clave que ese proveedor publica.

«Editasteis la respuesta que os mandamos.» Las respuestas se publican íntegras, sin editar y en su idioma original, y el remitente conserva su propia copia con su propia firma DKIM, que contradiría de inmediato cualquier alteración.

«Vuestro propio servidor podría estar mintiendo sobre todo esto.» Correcto, y por eso toda prueba que sostiene peso es externa: Bitcoin para el sello, la empresa certificadora para la entrega, la clave del proveedor para el mensaje, y un archivo de terceros para el registro. Nuestro servidor no custodia ninguna prueba que solo él pueda avalar.

9. La infraestructura

Las páginas estáticas y las funciones se ejecutan en Cloudflare Pages; el registro es una base de datos Cloudflare D1; el filtrado del formulario es Cloudflare Turnstile; los mensajes de confirmación se envían por un proveedor de correo transaccional cuya clave DKIM los firma; las tipografías se sirven desde este sitio.

En ninguna página hay analítica, publicidad, píxeles de seguimiento, huella digital del navegador ni incrustaciones de redes sociales. Las tipografías se sirven desde este sitio, no desde Google, así que el navegador de un visitante no llega a ningún otro servidor — salvo en las dos páginas del formulario, que cargan Turnstile, de Cloudflare, para impedir firmas automáticas. Se instala una cookie, y solo una vez has firmado: guarda el identificador de tu propia firma, para poder enseñarte el registro. Bloquea lo que quieras y el sitio sigue funcionando; simplemente los nombres quedan ocultos.

10. Si encuentras un error

Si algún hash no coincide, si alguna firma no valida, o si algo de esta página resulta inexacto, escribe a info@vedicvault.org. Lo comprobaremos y, cuando esté mal, lo corregiremos y diremos con claridad que lo hemos hecho. Una página de verificación que no admite una corrección no es una página de verificación.

Última actualización: . Volver al requerimiento · Condiciones y privacidad.