How to Prove a Prediction Was Made Before the Event (with OpenTimestamps)

The Problem: Look-Ahead

Everyone who has ever been right about something loud enough to remember it will tell you they called it. The screenshot arrives after the match, after the candle, after the election. And there is no way to know whether it was written on Monday or edited on Friday. This is the quiet rot at the center of most "track records": a prediction you cannot date is not a prediction at all. It is a memory with good lighting.

The technical name for the problem is look-ahead. If a forecast can be created, tweaked, or cherry-picked after the outcome is known, then it carries zero information about skill. The only fix is to make the timing of a prediction independently checkable - to prove a document existed in a specific form before a specific moment, without asking anyone to trust you, your server clock, or your database. That is precisely what OpenTimestamps does, using the Bitcoin blockchain as a shared, tamper-evident clock.

Why Timing Is the Whole Game

A forecast is a bet against the future. Its value comes entirely from the fact that the future was unknown when the forecast was fixed. The instant you allow post-hoc editing, every desirable property collapses: calibration becomes meaningless, Brier scores become fiction, and "I predicted this" becomes unfalsifiable.

So an honest forecasting system needs one hard guarantee before anything else: this exact text existed at this exact time, and has not changed since. Note what that guarantee does not require. It does not require publishing the forecast publicly in advance (you might want it sealed). It does not require a notary, a lawyer, or a trusted timestamping company that could be subpoenaed, hacked, or simply go out of business. It requires a clock that nobody controls and nobody can wind backward.

What "Proof of Existence" Actually Means

The building block is a cryptographic hash - typically SHA-256. Feed any file into it and you get a 64-character fingerprint. Change a single comma and the fingerprint changes completely. Crucially, the process only runs one way: from the fingerprint you cannot reconstruct the document, and you cannot craft a different document that produces the same fingerprint.

That property gives us a clean trick. Instead of proving "this document existed at time T," we only need to prove "this hash existed at time T." If the hash is provably that old, and the hash uniquely identifies the document, then the document is provably that old too. You never have to reveal the content to prove its age - you only reveal the hash. This is the difference between timestamping and publishing, and it is why sealed-then-scored forecasting is possible at all.

How OpenTimestamps Works, Step by Step

OpenTimestamps (created by Bitcoin developer Peter Todd) turns that hash into a permanent, verifiable anchor on Bitcoin. The flow looks like this:

1. Hash the document. Your forecast file is reduced to a single SHA-256 fingerprint on your own machine. The content never leaves your control.

2. Submit the hash to a calendar server. Free, public aggregator servers collect hashes from users all over the world during a short window.

3. Aggregate into a Merkle tree. The server combines thousands of these hashes into a single Merkle tree - a structure where every submitted hash is a leaf, and pairs of hashes are hashed together, level by level, up to one final value called the Merkle root. Your hash is now cryptographically bound to that root.

4. Anchor the root in a Bitcoin transaction. The server publishes just the Merkle root into a Bitcoin transaction. One transaction economically timestamps every hash in the tree at once, which is why the service can be free.

5. Wait for a block. When Bitcoin miners include that transaction in a block, the block header carries a timestamp and, more importantly, the immense proof-of-work behind it. From this moment on, your hash is provably older than that block.

The output you keep is a small .ots proof file. It contains the exact Merkle path from your document's hash up to the Bitcoin block - every sibling hash needed to walk from your leaf to the anchored root. That path is the whole proof, and it is self-contained.

Why Bitcoin Is the "Honest Clock"

You could, in principle, timestamp against any authority. The reason Bitcoin is the right one is that its clock is expensive to lie to. Each block is secured by proof-of-work - a global, ongoing expenditure of real energy. To move a confirmed transaction to an earlier or later block, an attacker would have to re-mine that block and every block after it, out-racing the entire honest network. Nobody can quietly backdate a hash into last week's block, because last week's block is buried under a mountain of accumulated work.

Just as important, no single party owns the record. There is no company whose database you must trust, no admin who can edit a row, no jurisdiction that can compel a change. The timestamp is agreed on by a decentralized network and replicated across thousands of nodes. That combination - costly to forge, owned by no one, checkable by everyone - is what earns Bitcoin the description of an honest clock. For forecasting, it means the proof of "when" survives even if the forecaster disappears.

How Anyone Can Verify a .ots Proof

The point of all this is independence: you should not have to trust the person showing you a proof. Given the original document and its .ots file, anyone can verify it - for example with the open-source client:

ots verify forecast.txt.ots

The verifier recomputes your document's hash, walks the Merkle path in the .ots file to reconstruct the anchored Bitcoin transaction, looks that transaction up in the blockchain, and reads the block's timestamp. If the document was altered by even one byte, the hash won't match and verification fails outright. If everything lines up, you get a concrete statement like "existed as of block N, mined on this date." No account, no API key, no faith in the publisher - just math and a copy of the blockchain (or a public block explorer).

Applying It to Accountability Forecasting

This is the backbone of how NeuPortal (neuportal.ai) runs its accountability experiment. Every forecast is locked - written, hashed, and timestamped through OpenTimestamps - before the event it describes. Once reality delivers the outcome, the prediction is scored with a Brier score and compared against prediction-market baselines. Because the lock happened first and is anchored to Bitcoin, there is no room to quietly delete a bad call or sharpen a good one after the fact.

The proofs are public. Our timestamped forecast records live in an open repository (github.com/neuportalai-ui/experiment-proofs), and the underlying dataset is archived with a citable DOI on Zenodo (10.5281/zenodo.21294229). Anyone can pull a forecast, run ots verify, and confirm for themselves that it predates the event. That is the entire difference between a highlight reel and a track record: one asks for your trust, the other hands you the tools to withhold it.

The Disclaimer That Matters

Timestamping proves when a forecast was made and that it hasn't changed. It says nothing about whether the forecast was any good - a confidently wrong prediction timestamps just as cleanly as a brilliant one. Proof of timing is a floor, not a ceiling: it makes honest scoring possible, but the scoring still has to happen in public, across many predictions, wins and losses alike. Read any timestamped record with that in mind.

Educational content - not financial advice, and not a betting tip.

Want to Check the Receipts?

• Browse our public, Bitcoin-timestamped forecast proofs at github.com/neuportalai-ui/experiment-proofs
• Cite the archived dataset via Zenodo DOI 10.5281/zenodo.21294229
• Follow the live scoring at neuportal.ai

Don't trust the claim - verify the timestamp.

NeuPortal Research