Verify, don't believe
method · 3 min read
Every page on this site ends with that sentence, and this page is what it means. Six checks, in rising order of effort. The first two run right here, in your browser, against systems I do not control. None of them needs my permission, and none of them needs your trust. The full record of dated claims these checks target sits at the priority and claims ledger: this page shows the checks; that page shows what the checks are checking.
The six checks
Hash what this site serves
Every load-bearing file has a published SHA-256. The tool below fetches the three verification scripts and recomputes their SHA-256s in your browser, with WebCrypto, sending nothing anywhere. It hashes the verifier, not the anchored manuscript itself: the raw manuscript object is held privately and its sent-side SHA-256 prefix is f0d1f38f, verifiable against a copy on request via data availability.
Resolve the signing key
The December and April records verify under a DKIM key published in DNS at google._domainkey.mastermindpromotion.com. Ask Google's or Cloudflare's resolver for it yourself with the second tool below and compare fingerprints against the 2 August 2026 capture.
Recompute a result
Clone the validation repository and start from its experiments index, which names every runnable suite with its commands; then follow the run-it-yourself steps on the evidence spine, and the environment and version pins on the reproducibility page. If a step fails, the claim fails, and I want to know. The programme DOI is 10.17605/OSF.IO/6C5XB; the paperback is ISBN 978-1-80605-620-0, published 2 January 2026, checkable in any library catalogue.
Read what has been wrong
The corrections log is append-only and dated, and it includes the retraction of my own headline number. A record with no corrections is a record nobody has checked.
Try to kill a claim
Every claim carries a stated kill-condition on the falsification dashboard, and every convergence links its primary source. One kill-condition has already fired. Click through, read the original, and check that the source says what the claim says it says.
Read the Bitcoin block
Both manuscripts, the 8 December 2024 record and the 30 April 2025 revision, carry an OpenTimestamps BitcoinBlockHeaderAttestation at block 961,340 (mined 6 August 2026), over merkle root 038418c1…abe42. The tool below prints the height and root you can open on any public block explorer, and the two ots commands that read the receipt with no node and verify it with one. A git commit date is forgeable via GIT_COMMITTER_DATE; a Bitcoin block header is not. The full treatment, including the exclusivity limit an anchor cannot establish on its own, is on the anchor page.
Check one, live: the files
Hash the verification tooling itself
Before you trust a verifier, hash the verifier. These are the exact files this site serves; the recorded values are from the 2 August 2026 release manifest. A match means the file served to you is byte-identical to the published record.
Check two, live: the key
Resolve the DKIM signing key from public DNS
Your browser asks a public resolver for the TXT record, decodes the published key, and compares its SHA-256 fingerprint to the value captured on 2 August 2026 (ef77ccfe…f09ebd13). Google's own ARC signing key at arc-20240605._domainkey.google.com is checked the same way.
Boundary, stated before you click: a match corroborates the key currently served, from your vantage, today. It does not establish what the DNS record held in 2024, and it does not verify a signature by itself. Resolving google._domainkey.mastermindpromotion.com proves the key exists; it does not prove that any particular message verified against it. The December record's signature mathematics were reproduced locally against keys returned on the audit date; the April record's verification is a supplied raw-source result with local reproduction pending. Those two statuses are different on purpose, and this tool upgrades neither.
Check six, at the chain: the Bitcoin anchor
Bitcoin block 961,340
Both the 8 December 2024 manuscript and the 30 April 2025 revision carry an OpenTimestamps BitcoinBlockHeaderAttestation at this height, over the same merkle root. The block was mined on 6 August 2026: the receipt freezes the bytes from that day forward, while the December date itself is carried by the sender-DKIM seal in check two. A block header cannot be back-dated without rewriting Bitcoin, so nothing here needs my permission or your trust. The two values a stranger needs are these, in plain text and copyable:
Block height: 961340
Merkle root: 038418c103704b8c307a645240ea54c874c8f758d39febd19f14a6fb8f7abe42
Read the block yourself on two independent public explorers, trusting no single operator: mempool.space/block/961340 and blockstream.info/block-height/961340. If both show the same merkle root, the height is not a fabrication.
If you hold an .ots receipt for one of the anchored files, read it with no Bitcoin node at all. This is the check almost every stranger should run first:
You should see, among other lines, BitcoinBlockHeaderAttestation(961340) and the same merkle root printed above. To verify the file itself against the anchor, with a local bitcoind reachable over RPC:
Read this before you run it, and read it again if it fails. ots verify requires a local bitcoind and it fails without one. A verifier without a node cannot read block headers, so the failure is about the node, not the receipt. A missing node is not a missing proof. The receipts themselves live in the repository’s priority-claims folder. If you cannot run a node, run ots info and read the same block height on a public explorer of your choice.
What the block commits to, said exactly
The block header at this height carries the merkle root through which the OpenTimestamps attestations for the two anchored manuscripts resolve: the 8 December 2024 package and the 30 April 2025 package, exactly those two files. It does not commit to the wider corpus, whose own root (237b94c4…ae094, over 1,463 files) lives in head.json and is a separate object; saying so here is the discipline that stops one anchor being over-read.
An anchor proves existence. It does not prove exclusivity. Nothing in the OpenTimestamps protocol stops a person stamping two competing manifests at the same moment and later publishing whichever the data comes to favour; Bitcoin will attest that each existed and cannot say that only one did. Two things close that gap. Hash-chained manifests: each new manifest declares the previous manifest’s root inside its own body, so a fork needs two published chains, not two private files, and a stranger can walk the chain from any head back to the genesis or refuse it. Contemporaneous publication of the head root: once the current head has been publicly reachable since a stated date, a competing manifest anchored at the same moment is a second public claim from that date rather than a private option held back. Neither alone is sufficient, and a page treating a bare anchor as proof of exclusivity would be overclaiming.
The chain, append-only. Head 1, the genesis: Bitcoin block 961,340, block merkle root 038418c103704b8c307a645240ea54c874c8f758d39febd19f14a6fb8f7abe42; corpus merkle root 237b94c4…ae094 over 1,463 files, full form in head.json; previous head: none. Later entries declare the previous head’s root inside their own body, so the entry that ever tries to fork the chain will be visibly missing a valid previous-root, and any stranger can spot it in one read. New heads appear here and in the changelog.
One dating discipline the anchor supports, restated because it is the one most often collapsed: the private date is 8 December 2024, carried by the sender-DKIM seal of check two; the first public date is 2 January 2026, in print with an ISBN. A per-paper upload date is not the programme’s first public date, and treating it as one collapses a year of the sequence.
What a pass does not establish
Authorship, originality, and the merit of any argument are untouched by every check on this page. Hashes establish that bytes are unchanged; resolving a key from public DNS establishes that this key is served by this domain, not that any particular message verified against it; a Bitcoin anchor establishes that these bytes existed by the moment the block was mined, and nothing more. An anchor proves existence, not exclusivity: nothing in OpenTimestamps stops a person stamping two competing manifests at the same moment and later publishing whichever the data comes to favour, so a single stamp is a floor on a date rather than a claim of uniqueness. What closes that gap is hash-chained manifests plus contemporaneous publication of the head root, both handled on the anchor page. None of that establishes that the ideas are any good. That part is still on me, and on you.
The standing offer
If you break a claim, the retraction goes on the record, publicly, with your name on it and your framing intact. That is not a risk I am taking; it is the product. A register that survives adversarial checking is worth something, and there is only one way to find out.
Found something? Send it.
A seventh check does not run in a browser, because it runs in a repository and a printed book. the dated prediction register lists every prediction this programme made before its evidence existed, with the artefact that fixes each date: a sealed record, an ISBN, a public commit history, and one prediction that failed and was retracted.
An eighth check needs no tool at all, only patience: read the work as it was being done. The laboratory notebook was kept live from 10 March 2026 and runs to 206 pages. It records the version that was wrong, the false positives that blinding exposed, and a list of the author’s own errors written at the moment he found them. A notebook is the one document that cannot be written afterwards. It is deposited on OSF at osf.io/j6mkb as well as published here, so the copy you check need not be one this programme controls.