MyCaseViewer

Verify a proof

How to check a MyCaseViewer timestamp proof against Bitcoin — without taking our word for any of it.

A MyCaseViewer certificate may carry a timestamp proof: a file ending .ots, alongside a hash. This page explains how to check it. Nothing here requires our cooperation, our servers, or our permission, and that is the point — a record only we can vouch for is a record worth very little.

1. What the proof establishes

It establishes one fact: the hash printed on the certificate existed no later than the moment the named Bitcoin block was mined. Bitcoin blocks cannot be rewritten after the fact, so a record committed to one cannot have been fabricated afterwards.

The hash covers the case's preservation history — the append-only, hash-chained log of every legal hold placed on or released from that case. If any entry in that history were added, altered or removed after the anchor, the hash would no longer match and the proof would fail.

1.1 What it does not establish

It does not prove that the events described occurred, that they occurred at the times recorded, or that any file is authentic. Everything before the anchor rests on our records. The proof is narrow on purpose: it fixes the record in time and claims nothing else.

2. How to verify it

The proof is an OpenTimestamps file, an open standard with a public reference client. We did not invent the format and cannot influence what the client reports.

2.1 With the command-line client

Install the OpenTimestamps client (pip install opentimestamps-client), then run: ots verify holdchain-XXXXXXXX.ots. It will report the Bitcoin block and the time it was mined.

The client checks the proof against a Bitcoin node. If you run your own node it consults that and trusts nobody; otherwise it falls back to public block explorers. That fallback is a trust assumption, and it is yours to make or refuse — not ours.

2.2 In a browser

The proof can also be checked at opentimestamps.org, which runs the same verification in the page. Note that this uploads the proof file to a third party. The proof contains only hashes and reveals nothing about the case, the files, or the people involved — but if that matters to you, use the command-line client.

2.3 Confirm the hash matches

Verification tells you when a hash was anchored. Check that it is the same hash: compare the digest the client reports against the chain head printed in the certificate's Independent Verification section. A valid proof for a different hash proves nothing about this record.

3. If the certificate says the anchor is pending

Anchoring takes one to three hours: submissions are aggregated by public calendar servers and committed to Bitcoin in batches. Until that completes, the certificate says so and offers no proof file. A pending anchor is a promise from a calendar server, not evidence, and we do not present it as one.

A certificate may also record that no anchor was obtained at all. The preservation history still verifies against our records in that case; it simply has no external corroboration.

4. Why we do not verify it for you

We could put a button on this page that reads the proof and tells you it is valid. We deliberately have not. A verifier written by the party offering the evidence, checking a proof issued by that same party, adds nothing an opponent should accept. The standard client exists, it is independent of us, and it is the right tool.

For the same reason, we do not operate the timestamping infrastructure. The calendar servers are run by others and the notary is the Bitcoin blockchain, which nobody controls.