Verify a Bitcoin timestamp yourself: step-by-step tutorial (no LegalStamp required)

You have received a contract.pdf file along with a contract.pdf.ots. The second is supposed to prove that the first existed at a given date. How can you verify this claim yourself, without having to trust the service that produced the .ots?

That is exactly what this tutorial covers. Three methods, from simplest to most rigorous, to verify an OpenTimestamps timestamp — the open standard that LegalStamp and several other services build upon. Two of these methods do not go through our website. That is intentional.

Why verifying it yourself changes everything

An electronic timestamp only carries evidentiary weight if the opposing party — or a judge, a peer, or simply your future self — can independently verify that the proof holds. If verification depends solely on the service that issued the certificate, you are transferring all the trust to that provider. What happens if they shut down? Change their terms? Get acquired? Your proof becomes unusable.

OpenTimestamps was designed in 2016 by Peter Todd (Bitcoin Core developer) precisely to avoid that trap. The .ots format is open and documented (public specification), and any compatible client can verify a proof produced by any other. Trust is carried by Bitcoin and by the standard, not by the issuer.

This is also at the heart of LegalStamp's argument: we make creation easier, but verification stays completely independent of us.

What verification actually proves

Before running a command, it helps to understand what is being verified. An OpenTimestamps proof establishes two things:

1. The SHA-256 hash of the original file matches the one recorded inside the .ots proof.
2. That hash was anchored in the Bitcoin blockchain at a specific date (the date of the mined block containing the anchor transaction).

In practice: if you change even a single character of the original file, the hash changes and verification fails immediately. If the Bitcoin transaction does exist in a dated block, the attestation date is locked — a miner cannot rewrite history without rewriting the entire chain, which is economically and technically out of reach.

The three available methods

Each method produces the same cryptographic result. The difference lies in the trust chain you mobilize.

Method 1: the LegalStamp /verify page

The simplest one. You drag your original file and its .ots into the drop zone, and the page immediately shows the Bitcoin anchor date and the block number.

Upside: zero installation, readable interface, verification in seconds. Limit: trust rests on the code we serve. For daily use that is fine, but for an adversarial demonstration methods 2 or 3 are preferable.

Try it on /verify →

Method 2: the official opentimestamps.org website

The OpenTimestamps project maintains an official web verifier, completely independent of any commercial service.

1. 1
   Open opentimestamps.org

   Go to https://opentimestamps.org. The Verify section is on the homepage.
2. 2
   Upload the original file

   Drop the file whose timestamp you want to verify (e.g. contract.pdf). The SHA-256 hash is computed locally in your browser; the content is not transmitted.
3. 3
   Upload the matching .ots

   In the second area, drop the corresponding proof file (contract.pdf.ots).
4. 4
   Read the result

   The verifier shows the Bitcoin block number, the precise UTC date, and the status. If the hash does not match or the proof is incomplete, an explicit error message indicates why.

This method is ideal to show a peer, a client, or a lawyer that the proof holds without going through your provider.

Method 3: the ots-cli command line (the most rigorous)

For those who want to verify without depending on any web service — including the OpenTimestamps one — the answer is the command-line client. It queries a public Bitcoin explorer directly, or better, your own local Bitcoin node.

1. 1
   Install the Python client

   On macOS or Linux: pip install opentimestamps-client. Requires Python 3.7 or higher. On Windows, WSL is recommended. Verify with ots --version.
2. 2
   Place both files in the same folder

   The client looks for the original file next to the .ots. If your proof is named contract.pdf.ots, the original file must be named contract.pdf.
3. 3
   Inspect the proof (optional)

   ots info contract.pdf.ots displays the internal structure: calendar servers used, Bitcoin attestation if present, Merkle path. Useful to understand the state of the proof without validating it.
4. 4
   Run the verification

   ots verify contract.pdf.ots queries a public Bitcoin explorer (by default) to retrieve the Merkle root of the relevant block and confirm the anchor. Response in a few seconds.
5. 5
   Verify against a local Bitcoin node (optional)

   If you run bitcoind: ots --bitcoin-node verify contract.pdf.ots. No dependency on a third-party explorer, 100% autonomous verification.

Full example

# 1. Installation
pip install opentimestamps-client

# 2. Make sure both files are present
ls -la contract.pdf*
# -rw-r--r--  1 user  staff  82341 May 02 10:14 contract.pdf
# -rw-r--r--  1 user  staff    540 May 02 10:15 contract.pdf.ots

# 3. Inspect the proof
ots info contract.pdf.ots
# File sha256 hash: 3a7bd3e2360a3d29eea436fcfb7e44...
# Timestamp:
# append e5b7...
# sha256
# verify BitcoinBlockHeaderAttestation(845231)

# 4. Verify
ots verify contract.pdf.ots
# Assuming target filename is 'contract.pdf'
# Success! Bitcoin block 845231 attests existence as of 2026-05-02 11:24:18 UTC

The Success! line is the cryptographic verdict. It means the SHA-256 hash of contract.pdf matches the one anchored in Bitcoin block 845231, mined at 11:24:18 UTC on May 2, 2026. Any later modification of the file — adding a character, changing a metadata field — would produce a different hash and break the verification.

Practical scenarios

You receive a .ots from a peer

A lawyer sends you a file and its .ots as an attachment. Before adding it to your case file, verify it. Methods 2 or 3 give you cryptographic certainty that the proof holds, regardless of the service that issued it.

You verify five years later

You find in your archives a contract timestamped in 2026. The service that issued it may no longer exist. No problem: as long as you have the original file and the .ots, the CLI or the official OpenTimestamps website will reconfirm the Bitcoin anchor date. The blockchain has not forgotten.

You produce the proof in court

The expert witness appointed by the opposing party will want to reproduce the verification independently. Documenting the protocol (CLI method, client version, exact command, full output) reinforces the credibility of the case file. That is a virtue few digital evidence formats offer.

So what is LegalStamp for?

Let's be clear: if verification is fully open, what are we for?

To handle creation and the lifecycle of the proof. Computing the SHA-256 hash in the browser without sending the file, submitting to multiple calendar servers, automatically retrieving the Bitcoin attestation once confirmed, archiving the .ots, tracking dozens or hundreds of files from a dashboard, handling GDPR. That is the invisible work that turns an open standard into a tool you can actually use day to day.

But verification stays public. That is a deliberate design choice: your proof must never depend on our survival. If LegalStamp disappears tomorrow, your .ots files will remain verifiable with any OpenTimestamps client. That is our strongest trust argument, and it is also the very nature of an open standard anchored on Bitcoin.

LegalStamp is a non-qualified electronic timestamping service under eIDAS: the proof does not carry the legal presumption reserved for qualified providers (QTSPs). However, Article 41(1) of the eIDAS regulation prohibits denying admissibility to an electronic timestamp on the sole ground that it is non-qualified. Combined with the robustness of Bitcoin and independent verifiability, the proof retains real evidentiary value.

FAQ

Conclusion

Knowing how to verify an OpenTimestamps timestamp yourself is not a technical detail: it is what separates a truly useful proof from a certificate that depends on a single provider. Three methods coexist, from the simplest web form to the most rigorous CLI, and all produce the same cryptographic verdict. That is the very definition of an open standard anchored on a public blockchain.

For LegalStamp, this independence is not a bug: it is the core feature. You can leave us tomorrow; your proofs will keep existing.

Disclaimer: this article is provided for educational purposes. It describes the technical procedure for verifying an OpenTimestamps timestamp. The evidentiary weight of a proof in a specific legal context will always depend on the overall case, the applicable procedural rules, and the sovereign assessment of the judge.