OpenTimestamps: A Practical Guide to Free Timestamping on Bitcoin

OpenTimestamps is the reference tool for understanding how Bitcoin-anchored timestamping works. Designed by Peter Todd (Bitcoin Core developer) in 2016, it relies on a simple principle: aggregate thousands of timestamp proofs into a single Bitcoin transaction via a Merkle tree, then distribute the individual proof to each user.

It is technically brilliant — and it is also the low-level layer that professional timestamping services like LegalStamp use under the hood, adding everything raw CLI does not provide: interface, archiving, automated verification, GDPR architecture, support, and qualified eIDAS legal presumption.

This article first explains how OpenTimestamps works "raw", then why an integrated service is the right choice in 90% of professional cases.

OpenTimestamps gives your hash the resistance of Bitcoin itself. But without archiving, monitoring, or qualified legal presumption, the entire operational risk lands on your shoulders.

How it works (in 90 seconds)

OpenTimestamps combines two ingredients:

1. A Merkle tree: thousands of user hashes are grouped into a single root.
2. A Bitcoin transaction: this root is inscribed in an OP_RETURN transaction on the Bitcoin network, roughly once per block (10 minutes on average).

The result: each user receives a .ots file (OpenTimestamps proof) containing the Merkle path linking their hash to the Bitcoin transaction. This proof is:

• Verifiable offline (with a local Bitcoin node) or via a public explorer.
• Independent from the server that generated it (resistant to provider disappearance).
• Final once attested by Bitcoin (no posterior modification possible).

Installation: 3 paths depending on your profile

Option 1 — Online client (zero installation)

For occasional needs, the official site opentimestamps.org offers a web interface that timestamps a file without any installation. Drag and drop, get the .ots immediately.

Limits: one file at a time, no automation, dependency on a third-party site.

Option 2 — Python client (CLI, recommended)

For automation and full control:

# Install via pip
pip install opentimestamps-client

# Verify
ots --version

Prerequisites: Python 3.7+. Available on Linux, macOS, Windows (WSL recommended).

Option 3 — JavaScript / Node.js

For application integration:

npm install opentimestamps

Usable in browser or server-side Node.

Timestamping a file: the essential commands

1. 1
   stamp — create the proof

   ots stamp my_file.pdf — generates a my_file.pdf.ots file containing the proof. The SHA-256 hash of the file is sent to calendar servers.
2. 2
   info — inspect the proof

   ots info my_file.pdf.ots — shows the proof state: calendar servers used, Bitcoin attestation if already inscribed, Merkle path.
3. 3
   upgrade — fetch the Bitcoin attestation

   ots upgrade my_file.pdf.ots — queries servers to retrieve the Bitcoin attestation once the transaction is confirmed. Run after a few hours.
4. 4
   verify — check the proof

   ots verify my_file.pdf.ots — verifies that the file's hash matches the one inscribed on Bitcoin at the attested date. The result displays the exact anchoring timestamp.

Complete example

# 1. Start with a file
ls -la report_2026.pdf
# -rw-r--r--  1 user  staff  124583 Apr 30 09:00 report_2026.pdf

# 2. Timestamp it
ots stamp report_2026.pdf
# Submitting to remote calendar https://a.pool.opentimestamps.org
# Submitting to remote calendar https://b.pool.opentimestamps.org
# Submitting to remote calendar https://finney.calendar.eternitywall.com

# 3. Get the proof file
ls -la report_2026.pdf*
# -rw-r--r--  1 user  staff  124583 Apr 30 09:00 report_2026.pdf
# -rw-r--r--  1 user  staff    540 Apr 30 09:01 report_2026.pdf.ots

# 4. Hours later, fetch the Bitcoin attestation
ots upgrade report_2026.pdf.ots
# Got 1 attestation(s) from https://a.pool.opentimestamps.org
# Success! Timestamp complete

# 5. Verify
ots verify report_2026.pdf.ots
# Got 1 attestation(s) from https://a.pool.opentimestamps.org
# Success! Bitcoin block 845231 attests existence as of 2026-04-30 11:24:18 UTC

Verifying a proof without installing Bitcoin

The OpenTimestamps client can verify via:

1. A local Bitcoin node (most robust method, but requires ~600 GB of storage)
2. A public Bitcoin explorer like Blockstream Explorer (default method, sufficient for most cases)

To configure a local node:

# If you run bitcoind
ots --bitcoin-node verify my_file.pdf.ots

Otherwise, the client uses the public explorer — fully transparent for the user.

Concrete use cases

For a freelancer / consultant

• Timestamp each deliverable when sent to the client.
• Store the .ots with the original PDF in the project folder.
• In a dispute, present the file + the proof: the send date is attested by Bitcoin.

For a photographer

• Timestamp the high-resolution RAW file before any publication.
• For an urgent assignment, batch all files of a memory card.

for f in *.RAW; do ots stamp "$f"; done

For a developer

• Timestamp a precise version of source code (Git archive or tarball).
• Pair with a GPG commit signature to identify the author.

git archive --format=tar.gz --output=project-v1.2.0.tar.gz HEAD
ots stamp project-v1.2.0.tar.gz

For a team / company

• Integrate ots stamp into the CI/CD pipeline to timestamp each release.
• Store .ots files in a dedicated repository or digital vault.
• Automated periodic verification via cron.

Limits to know

Attestation latency Final inscription on Bitcoin takes from minutes to several hours. Public calendar servers batch submissions per block.

No strong legal presumption Unlike a qualified eIDAS timestamp (Article 42 of EU Regulation 910/2014), OpenTimestamps is not accompanied by a recognized presumption of accuracy. It is technically very strong preliminary evidence, but always assessed case-by-case.

Initial dependency on the calendar server Between stamp and upgrade, the proof depends on the calendar server. If a server fails before Bitcoin anchoring, the proof can be lost. Submitting to multiple servers (the client uses 3 by default) limits this risk.

Dating granularity The attested date is the Bitcoin block's (precision: ~10 minutes on average). Sufficient for most disputes, but worth knowing if second-level precision is critical.

The real limits in professional use

The tutorial above shows OpenTimestamps "as is". Here is what surfaces immediately when you use it in production on real-stakes files:

No source file archiving OTS only handles the hash. You handle everything else: file storage, backups, 3-2-1 redundancy, retention duration. A .ots proof without the source file = inoperative proof.

No automated long-term verification No one runs ots verify quarterly across 500 files. Without integrity monitoring, bit rot or media corruption goes unnoticed for years.

No qualified legal presumption OTS is strong technical preliminary evidence, but no eIDAS presumption. In high-stakes litigation (>€50k), qualified timestamping is largely preferable.

No GDPR by design You build your own erasure procedure, records of processing, processor contracts, international transfer framework. The first DPA audit lands entirely on you.

No support, no SLA Public calendar servers are best-effort, no service-level agreement. If they fail at the worst moment, no recourse.

No collaborative audit trail Who timestamped what, when, for which project? OTS says nothing. For a team, it is unmanageable beyond a handful of files.

Raw OpenTimestamps vs LegalStamp

In short: OpenTimestamps is free in money but expensive in time and operational risk as soon as you go beyond ad-hoc use. LegalStamp embeds OpenTimestamps in the background and adds the entire pro layer that turns a technical proof into an exploitable case file.

See how LegalStamp handles all of this for you →

Common mistakes

Forgetting to run ots upgrade → As long as upgrade hasn't fetched the Bitcoin attestation, the proof depends on calendar servers. Run upgrade a few hours (ideally a few days) after stamp.

Modifying the file after timestamping → The hash changes → the proof becomes invalid. If modification = new version = new timestamp.

Keeping only the .ots without the original file → The .ots doesn't contain the content, only the hash trail. Without the file, impossible to verify what was timestamped.

Relying on a single calendar server → Always let the client submit to multiple servers by default (3). This avoids losing the proof if a server fails.

Not verifying periodically → A .ots proof can be corrupted (bit rot). Annual verification recommended.

FAQ

Conclusion

OpenTimestamps is a remarkable technical building block: open source, Bitcoin-anchored, verifiable for life. If you're a developer and want to timestamp a one-off file, run ots stamp — that's the most solid free option around.

But in professional use — client deliverables, contracts, protected creations, HR files, pro photography — raw CLI leaves on your shoulders everything that turns a hash into truly exploitable evidence: source file archiving, long-term verification, GDPR records, qualified legal presumption, team tracking, support.

That's exactly what LegalStamp does: we embed OpenTimestamps and an eIDAS qualified timestamp in the background, then add the pro layer (drag-and-drop interface, NF Z42 archiving, automated verification, dashboard, GDPR by design) that makes the proof usable day-to-day — no IT project to set up.

For most creators, freelancers and businesses, the right shortcut is simple: start with LegalStamp, and keep OpenTimestamps as an option for specific cases (independent audit, developer integration).

Disclaimer (general information): this article is provided for educational purposes and does not constitute legal advice. The evidentiary weight of an OpenTimestamps proof always depends on the dispute context, applicable procedural rules, and the overall quality of the case file.