Skip to content

For publishers

A short page you can send to your editor ahead of delivery.

Your author is delivering their manuscript with a small companion document — a proof bundle — that demonstrates, independently verifiably, that the manuscript you are receiving is the same file they have been working on over time. This page explains what it is, what it is not, and what you will need to do to check it.

What you are getting

Alongside the manuscript, a single zip file — the proof bundle — containing four items:

  • A PDF with a cover page, an attestation of authorship, a word-count-over-time chart, and a short cryptographic appendix. It contains no manuscript content.
  • A canonical record (a small JSON file) with the cryptographic fingerprints of the author's saves, the dates on which they were registered, and the stamps from a public timestamping service.
  • A signature file that shows the record came from BlindProof and has not been altered.
  • A checking tool — a single small Python script — that verifies all of the above, on its own, with no call back to BlindProof.

What it proves

Run against the manuscript you have just received, the tool confirms three things in turn:

  1. The signature on the bundle is valid. The record has not been tampered with.
  2. The manuscript you hold matches an entry in the author's timeline. The fingerprint of the file you received appears in the record, on a specific date.
  3. The public registrar's stamp on that date is genuine. The tool checks this against the public record directly — this is the part that cannot be faked retroactively.

If all three pass, you have a mathematically unambiguous statement: this exact manuscript, byte-for-byte, existed on these dates, registered at an external public service that cannot be backdated. A different manuscript of similar length would not match. Changing a single comma would break the check.

What it does not prove

It does not prove which human was at the keyboard. For that, your usual evidence still applies — contracts, editorial correspondence, your relationship with the author. The bundle is one additional piece, and the one hardest to invent after the fact.

How to run the check

You need a computer with Python 3.12 or later installed, and an internet connection for the parts of the check that reach the public registrar. On most macOS and Linux systems, Python is already available; Windows users can install it in a few minutes from python.org. Confirming the Bitcoin anchor automatically also needs a Bitcoin node; without one, that single step is reported as not confirmed here (see below) rather than failing — internet access alone does not complete it.

The bundle ships as a single zip file (typically named BlindProof-<date>.zip). First, unzip it — that exposes verify.py alongside bundle.json, bundle.sig.json, and bundle.pdf.

From a terminal, in the unzipped folder, run the structural check:

uv run verify.py .

This confirms the signature and the timeline. Fully confirming the public timestamp's Bitcoin anchor needs a Bitcoin node; without one the tool reports that step as not confirmed here (see below) rather than failing the run. Then, to confirm the manuscript you received matches an entry in that timeline, add --manuscript:

uv run verify.py . --manuscript path/to/the/manuscript.md

(If you do not have uv installed, plain python verify.py … works too, after a one-line pip install opentimestamps-client cryptography.)

The tool prints a short report: one line per check, ending in PASS, pending, or FAIL. A "pending" OTS result for a very recent save simply means the public stamp has not yet been anchored — the author can produce another bundle in a day or two, or you can re-run the check when convenient. Fully confirming that public anchor needs either specialist software (a Bitcoin node) or the public verifier at opentimestamps.org; on an ordinary computer the tool simply notes that the anchor was not confirmed here and passes the remaining checks. That is expected, and not a fault in the bundle. A MATCHED manuscript line means the file you received is, byte-for-byte modulo line endings, one of the saves the author registered. NOT MATCHED means the file you received is not that version — contact the author.

If you need help

The checking tool is deliberately small, stdlib-only, and readable. Your technical team can audit it in an afternoon if they wish. BlindProof does not need to be involved in the verification — in fact, not needing us is the point. If you have questions about what a particular result means, or want a walkthrough with your IT team, we are happy to help without ever seeing the manuscript.