Strata

Verifying a claim

For the person on the receiving end, who has no reason to trust the software that produced the record.

Someone has given you a manuscript and told you it carries a verifiable record. This page shows you how to check that yourself. It takes about five minutes and uses two tools, neither of which we wrote: a SHA-256 utility that ships with your operating system, and the reference OpenTimestamps client.

If at any point these instructions require you to run Strata, or to trust something Strata says, we have failed and you should say so.

Before you start

  1. The canonical text — a plain-text file, exported from the record
  2. The timestamp proof — one or more .ots files
  3. The claim — what the author says this is, and when

Install the reference client if you don't have it:

pip install opentimestamps-client

  1. Confirm the text hashes to what is claimed

    The record identifies a document by the SHA-256 of its canonical text. Compute it:

    shasum -a 256 manuscript.txt

    Compare the result to the doc_hash in the record. If they differ, the text you were given is not the text that was recorded — full stop. It does not matter how small the difference is; a single changed character produces an unrelated hash.

    Caution

    Hash the file exactly as supplied. Opening it in an editor and saving may add a trailing newline or change line endings, either of which changes the hash. That is a property of hashing, not evidence of tampering.

  2. Read the timestamp proof

    Confirm the proof refers to the same document, and see what it commits to:

    ots info manuscript.txt.ots
File sha256 hash: 0450d4dfcf8916ef34088def552f497450a614d3bc…
Timestamp:
append c7eba69a11b7f766
sha256
…
verify PendingAttestation('https://alice.btc.calendar.opentimestamps.org')

    The File sha256 hash line must match what you computed in step 1. If it does not, the proof belongs to a different document.

  3. Verify the timestamp against Bitcoin

    ots verify manuscript.txt.ots

    You will get one of two answers, and the difference matters:

    ✓Success! Bitcoin block 8… — the document existed no later than that block's timestamp. This is anchored to Bitcoin, not to anyone's assurance.
    ◦Pending confirmation — a calendar operator has committed to including it, but Bitcoin has not confirmed yet. This is a promise from a named third party. It usually resolves within a few hours; run ots upgrade and check again.

    Treat pending as what it is. It is meaningfully better than nothing and meaningfully worse than confirmed, and any interface presenting the two identically is misleading you.

  4. Read the chain, if you were given one

    A single timestamp proves one state existed by one time. A chain is more informative: each recorded state references the one before it, so a sequence of witnessed states shows work accreting across real elapsed time.

    Check that each entry's stated parent matches the previous entry's identifier, and that witnessed times increase. A record that skips, loops, or reorders is not evidence of anything — and unlike the text, it costs you nothing to check.

What you have now established

If every step passed, you know three things with a high degree of confidence:

  • The text you hold is byte-identical to what was recorded.
  • It existed no later than the witnessed time.
  • It sits in a sequence that could not have been reordered or backdated afterwards.

What you have not established

Please read this part as carefully as the rest.

  • Not that a human wrote it. A record of incremental accretion is consistent with a person writing, and also with someone pasting generated text in increments over time. It raises the cost of that deception considerably. It does not eliminate it.
  • Not what happened before the first witnessed state. Nothing can be witnessed retroactively. Imported history carries the author's asserted dates, which are recorded and explicitly untrusted; only states witnessed after import are proven.
  • Not that the author is anyone in particular. There is currently no signature at all: a state is bound to a time, not to a key and not to a person. Two people could produce identical records over the same text, and the only thing separating them is which was witnessed first.

    Signing is a planned capability and it belongs to the provenance agent, not to the editor — the key must never enter the writing tool’s memory. When it exists, a record will also say under this key. It does not yet, and this page will say so until it does.
On absence

A writer with no record has told you nothing, and must not be treated as having told you something. Almost all writing that has ever existed was made without one — including, presumably, most of the writing you value. A thin record is a habit, not a fact about authorship: someone who saves twice a day produces a fraction of the entries of someone who saves constantly.

The patterns that look suspicious usually aren't. Mostly-paste means a draft that began somewhere else. Few large entries means someone who writes in long sittings. Long gaps mean a job, or children, or illness.

When a check doesn't pass

SymptomMost likely cause
Hash mismatch, text looks identicalWhitespace, line endings, or a trailing newline introduced in transit
ots info shows a different file hashProof and document have been paired incorrectly
Pending for more than a dayRun ots upgrade; if it persists, that calendar may not have published
Chain parent doesn't matchEntries supplied out of order, or an incomplete extract

Most failures are transit problems, not fraud. Ask for the files again before drawing a conclusion — and ask for them in a way that cannot rewrite them, which usually means an archive rather than a document attachment.