What makes a digital timestamp legally defensible.

The four properties

A digital timestamp is defensible to the extent it satisfies all four of the following:

• Cryptographic binding to a specific file. The timestamp must commit to the byte-exact contents of the file in a way that any later substitution becomes visible.
• Public, independent anchoring. The date must be fixed by a record outside the issuer's control, so the issuer cannot quietly backdate or alter what was stamped.
• Independent verifiability. A challenger must be able to confirm the timestamp using their own tools, without relying on the issuer's database or word.
• Continuity beyond the issuer. The timestamp must remain verifiable if the issuer closes, is sold, is compromised, or becomes a party to the dispute.

Each is necessary. Together they are sufficient for the narrow question a timestamp answers — that a specific file existed by a specific date — to survive cross-examination.

Property one — cryptographic binding

A file system "last modified" date binds to the file system, not to the file. Copying the file resets the date. Editing one byte does not. The conventional timestamp is decoupled from the bytes it appears to describe.

A SHA-256 fingerprint binds to the bytes themselves. Change one bit anywhere in the file and the fingerprint changes completely. There is no known way to construct a different file with the same SHA-256 fingerprint in the time the universe has been around. So when a timestamp commits to a fingerprint, it commits to a specific byte sequence — and any later attempt to substitute a different file is immediately visible to anyone with both the original and the recorded fingerprint.

Property two — public, independent anchoring

If the date of a timestamp is recorded in a database the issuer controls, the issuer can change it. That is true whether the issuer is a notary, a software vendor, a cloud provider, or a government office. Defensibility under cross-examination requires the date to be fixed somewhere the issuer cannot reach.

The office uses the Bitcoin chain as the anchor. The chain has a sixteen-year track record without a reorganization past about six blocks. No one party controls it. The mined timestamp of a block is visible to anyone with a copy of the chain — which is to say, anyone with a moderately fast internet connection and a few hours of disk space. To alter the recorded date, an adversary would need to alter the chain itself, which has not been done at scale by any party, public or private, since the chain began.

The architectural explainer is at /method/bitcoin-attestation.html.

Property three — independent verifiability

A defensible timestamp does not require the verifier to trust the issuer. The verifier needs only the file, the receipt, and any standard SHA-256 tool. The receipt's proof files reveal the block height and timestamp; any copy of the Bitcoin chain confirms when that block was mined. Nothing in that loop touches the office's servers.

A reference verifier under MIT is published at /method/the-mit-verifier-annotated.html. The verifier is a few hundred lines of code and runs offline once the chain is local. Any opposing party, court-appointed expert, or auditor can run it without an account, an API key, or a cooperation request to the office. That is what verifiability without trust means in practice.

Property four — continuity beyond the issuer

Every conventional timestamp service inherits a weakness from the structure of the service itself: the date is real until the company stops paying its hosting bill. When the database goes dark, the receipts in customer hands point at a tombstone. The proof is gone.

The office's receipts do not have that property. The proof is in the file the customer holds, the fingerprint the file produces, and the block height encoded in the .ots proof file. The office is a convenience for issuing the receipt; the receipt itself is independent of the office. If the office closes tomorrow, every receipt issued today still verifies tomorrow, next year, and as long as the Bitcoin chain is running. A treatment of this property is at /blog/why-domain-dying-doesnt-kill-your-timestamp.

Why everyday timestamps fail at least one property

Document metadata

Fails binding (metadata is decoupled from content) and anchoring (metadata is editable). Useful as a soft cue, not as evidence.

Screenshots of a clock or a calendar

Fails binding (the screenshot is one image, not the document it claims to date) and verifiability (the verifier cannot independently confirm the clock was correct or unaltered).

Email headers

Stronger than metadata when the receiving mail server is trustworthy, but fails continuity (the headers depend on the receiving provider's records) and partially fails anchoring (a sophisticated party can fabricate plausible headers).

Centralised timestamping services

Often satisfy binding and verifiability, but fail anchoring (the date lives in the vendor's database) and continuity (the vendor can close). The defensibility lasts as long as the vendor does.

Bitcoin-anchored timestamps

Satisfy all four properties when implemented through a public standard with multiple independent calendars and a chain-based anchor. That is the configuration the office runs. The redundancy argument for using five calendars rather than one is at /blog/why-5-opentimestamps-calendars-not-1.

What defensibility does not mean

• It does not mean a court will admit the receipt automatically. Admission depends on jurisdiction, on the relevance of the underlying fact, and on the foundation laid by counsel. The receipt is evidence; admissibility is a separate question.
• It does not mean the receipt proves authorship, signing, or delivery. It proves a specific byte sequence existed by a specific block. Those other questions are litigated on their own evidence.
• It does not mean the receipt is irrebuttable. A counterparty can argue the file was anchored after fabrication, that the wrong file was anchored, or that the surrounding context is misleading. The receipt only forecloses the one specific argument that the file did not exist by the recorded date.

Try it

Open orphograph.com. Drop any file. The browser hashes it on the device; the office anchors the fingerprint through five independent calendars and into the Bitcoin chain. The receipt that comes back satisfies the four properties above and will be verifiable by any third party for as long as the chain is running.