How to prove a document was not rewritten later
A project publishes a whitepaper. Six months later the numbers on the site are different, and the paper on the site matches the site. Was the paper changed? Usually there is no way to tell — and there is an easy way to make it tellable.
Why the obvious answers do not work
- The date in the document. Typed by whoever wrote it, editable by whoever edits it.
- The file’s modification date. A property of your copy, not of the document. Copying resets it.
- The publication date on the page. A field in a database the publisher controls.
- The Internet Archive. Genuinely useful, and outside the publisher’s control — but it captures what it happened to visit, when it happened to visit. No capture, no evidence.
None of these is dishonest by nature. They are simply not evidence, because the party they are supposed to constrain is the same party that controls them.
What actually works
Two pieces, and neither requires trusting the publisher.
A checksum — a SHA-256 hash — is a short string computed from the bytes of a file. Change one character anywhere and the string changes completely. It cannot be reversed and it cannot be forged: you cannot craft a different document with the same hash. So a published hash pins down one exact file.
A timestamp proof ties that hash to a moment in time by committing it into the Bitcoin blockchain. Rewriting the record would mean rewriting Bitcoin. What it proves is narrow and useful: this exact file existed no later than this block.
Together they answer the question completely. The hash says which file. The proof says when it existed. Neither goes through the publisher, and both can be checked by anyone with a terminal.
Checking one in two commands
Download the document and its proof file, usually a small file ending in .ots sitting next to it. Then compute the hash and compare it with the published value:
sha256sum document.docx
If it matches, you hold the exact file that was published. Now verify when it existed, using the OpenTimestamps client:
ots verify document.docx.ots
The client reports the Bitcoin block and its date. That is the proof, and it does not contact the project at all — only the blockchain.
One practical warning that catches people out: opening a document in a word processor and saving it, even with no edits, rewrites the bytes. The checksum then fails and the proof no longer matches. Verify before you edit, and keep the original.
What it proves and what it does not
- Proves: this file existed in this exact form on or before that date.
- Does not prove: who wrote it. Anyone can timestamp anyone’s document.
- Does not prove: that its contents are true. A timestamped forecast is a forecast with a date.
- Does not prove: that it was the only version. A project can timestamp several drafts and show you the flattering one — which is why the set of published proofs matters as much as any single proof.
Why so few projects do it
It costs nothing. The calendars are free, the client is a package install, and stamping takes a second. The reason it is rare is not cost — it is that it removes an option. Once a document is timestamped, the quiet revision is off the table, and the numbers in it have to be defended rather than adjusted.
Which makes its absence informative. A project that publishes documents without checksums is not necessarily hiding anything. A project that publishes checksums is telling you it has accepted a constraint, and you can verify the constraint holds.
Common questions
Do I need to run a Bitcoin node?
No. The client checks the proof against public block data. Running your own node removes even that dependency, but it is not required for the check to be meaningful.
What if the proof says “pending”?
The stamp was made but has not been anchored in a block yet — usually an hour or so. A pending proof is not a failed proof, but it still depends on the calendar server until it is upgraded.
Can a project fake the timestamp?
Not the timestamp. It could stamp a document and publish a different one, which is why you compute the hash of the file you actually downloaded and compare — that step is what closes the gap.
How this project uses it
Every document published on this site carries a SHA-256 checksum and an OpenTimestamps proof anchored in Bitcoin. Older versions are never removed when a new one appears, so the whole sequence stays checkable rather than just the current file. The checksum is never written inside the document itself — a document cannot contain its own hash — it lives on the documents page next to the file.
The commands above are the same ones we use. Run them on our documents; if anything fails to verify, that is worth telling us about.