Technical note

How this is verified, and what each proof is worth

This document describes every mechanism used on this site, so that a reader who wishes to check the claims can do so without trusting us at any point. It also states, for each mechanism, exactly what it establishes and what it does not. A proof that is oversold is worse than no proof, because the exaggeration becomes the story.

1. The sealed text

The canonical text of the demand is a plain UTF-8 file, letter-en.txt, containing no markup, no metadata and no invisible characters. Plain text is used deliberately: a PDF or a word-processor file carries hidden state that changes between saves, so its hash would change without the visible text changing, and the seal would prove nothing.

Its SHA-256 digest is: 

3e8818711246be7c15c49c5d57f6c20c0af9a46c3e47add2e8e7ed952f4216c9

The Spanish text is a separate file with its own digest, a91961afd6e9ef16c60123357f1de6b341d755eb95b74cc2f0e99b87dfe4e25d, sealed independently and labelled throughout as a reference translation.

2. Anchoring the seal in Bitcoin

A hash published on our own site proves nothing on its own: we control the site, so we could publish any hash at any time and claim it was there earlier. The anchor is what removes us from the chain of trust.

The digest was submitted to the OpenTimestamps calendars a.pool.opentimestamps.org, b.pool.opentimestamps.org, a.pool.eternitywall.com and ots.btc.catallaxy.com, which aggregate submissions into a Merkle tree and commit its root to a Bitcoin transaction. The resulting receipt is published at letter-en.txt.ots, and the Spanish one at letter-es.txt.ots.

To verify independently, without visiting this site for anything but the two files: 

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          # must match the digest above
ots verify letter-en.txt.ots     # confirms the Bitcoin attestation

What this establishes. That a file with exactly this content existed no later than the block in which the commitment was mined. Producing a false earlier timestamp would require rewriting Bitcoin's history.

What it does not establish. Authorship. A timestamp says when, never who. Anyone could have stamped this text. Attribution here rests on the ordinary evidence of publication, not on cryptography, and we make no stronger claim.

A note on latency. An OpenTimestamps receipt is issued immediately but upgrades to a complete Bitcoin attestation once the calendar's commitment is mined, typically within a few hours. Running ots upgrade before verifying will fetch the completed path.

3. Permanent storage

The text is additionally stored on Arweave, a network with no owner and no delete operation, so that the document survives the loss of this domain, this host, or us. Until that upload is made the site says so; it does not claim it in advance.

Arweave provides durability, not integrity. Integrity comes from the hash. The two are separate properties and are stated separately.

4. Signature integrity

Submitting the form writes a pending record and sends a single-use token to the address given. The record becomes active only when that token is presented. Pending records are never counted, never displayed, and are deleted after thirty days.

This double confirmation defends against the two attacks that actually matter to a register of this kind. The first is impersonation: adding a well-known devotee's name without their knowledge, which fails because the confirmation goes to an address the attacker does not control. The second is inflation: manufacturing thousands of signatures to make the list look larger, which fails because each requires a distinct, working mailbox.

The email address is the unique key of the register. The same address cannot appear twice, whichever language page it was submitted from — the two pages are two front ends over one system, not two systems.

Form submissions are additionally screened by Cloudflare Turnstile, a privacy-preserving challenge that sets no cookie and performs no cross-site tracking.

Entries in the group of disciples initiated by Śrīla Prabhupāda are reviewed by a person before appearing in that group, and the year and place of initiation given are published beside the name. That publication is the verification: a false claim of initiation, with a stated year and place, is visible to everyone who was present, in a community where such a claim cannot survive a week. No cryptographic mechanism could achieve this, and none is claimed.

5. Why the register is deliberately not sealed

The register of signatures is stored in an ordinary mutable database. It is not hashed, not anchored, and not written to any permanent medium. This is a design decision and not an oversight.

An immutable list of names is a trap. A devotee who signs today and comes under pressure in six months must be able to disappear from it completely, and a permanent record would make that impossible. Permanence is applied to the text, which needs protecting, and withheld from the list of persons, who need protecting from permanence.

The cost of this decision is that we cannot cryptographically prove the register was not edited. We accept that cost, we state it here rather than let it be discovered as an objection, and we offer the ordinary compensations instead: the register is published continuously in machine-readable form at /api/register, and anyone may archive it at any time through a third party such as the Internet Archive, producing an external record that we cannot alter.

6. Evidence of delivery

Each recipient of the demand receives an individually addressed message. No bulk mailing is used, and no blind copy list, at any stage. This matters evidentially: a message addressed to one person is evidence about that person, while a blind copy proves only that a list existed.

Three artefacts are retained for each delivery.

The certificate. For principal recipients, the message is additionally processed by an independent certification service, which issues a signed PDF attesting to the content, the recipient and the moment of delivery. This is the artefact a non-technical reader can evaluate, and it is issued by a company with no relationship to us.

The message file. The original .eml is retained with its headers intact, including the Message-ID and the DKIM-Signature added by the sending provider. DKIM signs the body and a set of headers with a private key whose public half is published in the provider's DNS. Anyone may fetch that key and confirm that the message content, sender, recipient and date have not been altered since sending. This is the strongest artefact of the three, because it depends on neither us nor the certification company.

The digest. The SHA-256 of the message file is recorded in the register at the moment of sending, so that the file cannot later be substituted.

Where a recipient's address is already published by the organisation itself, the complete .eml is published so that its DKIM signature can be validated by anyone. Where the address is not public, the address is masked, and masking necessarily breaks DKIM validation — so for those recipients the certificate and digest are published and the unmasked file is supplied on request. We would rather explain this asymmetry than publish a private address or an unverifiable file.

7. What the record establishes, precisely

It establishes that a document in a specific form existed on a specific date; that it was addressed to a named person at an address they use; that it was accepted for delivery by the receiving mail system; and whether a reply was received within the period stated in advance.

It does not establish that the recipient opened the message, or read it, or understood it. No email system can establish that, read receipts included, and we make no such claim anywhere on this site. We state the limit ourselves because a record that overstates itself invites the whole record to be dismissed on the strength of the one exaggeration.

8. What an adversary could say, and the answer

“You changed the text after people signed.” The hash is anchored in Bitcoin and the anchor predates the signatures. Any change to any character breaks the verification, which anyone can run in four commands.

“You invented the signatures.” Every one required a working mailbox and a confirmation click. Names in the initiated group carry a year and place of initiation and are checkable by the people who were there.

“You added names to the invitation list afterwards.” Each row is published on the day the message is sent, not afterwards, and the register is publicly archivable by third parties at any moment.

“You never actually sent it.” The DKIM signature on the retained message file is produced by the sending provider, not by us, and can be validated against that provider's published key.

“You edited the reply we sent you.” Replies are published in full, unedited, in the original language, and the sender holds their own copy with their own DKIM signature, which would immediately contradict any alteration.

“Your own server could be lying about all of it.” Correct, which is why every load-bearing proof is external: Bitcoin for the timestamp, the certification company for the delivery, the sending provider's key for the message, and a third-party archive for the register. Our server holds no proof that only our server can vouch for.

9. The stack

Static pages and functions run on Cloudflare Pages; the register is a Cloudflare D1 database; form screening is Cloudflare Turnstile; confirmation messages are sent through a transactional email provider whose DKIM key signs them; typefaces are served by Google Fonts.

There are no cookies, no analytics, no advertising, no tracking pixels, no fingerprinting and no social embeds on any page. The only external request a visitor's browser makes is for the typefaces, and the site remains fully usable if that request is blocked.

10. If you find an error

If any hash fails to match, any signature fails to validate, or anything on this page proves inaccurate, write to restore@vedicvault.org. We will check it, and where it is wrong we will correct it and say plainly that we have done so. A verification page that will not accept a correction is not a verification page.

Last updated . Return to the demand · Terms and privacy.