Findings · 2026-09-08 · By VSNARY | Emmanuel Orta · 1 view

Our proofs said “pending” for 26 days. The anchoring was fine.

Every timestamp file this site served was a calendar receipt rather than a finished Bitcoin proof. The record was unbroken the whole time; the artifact handed to a reader did not show it.

On 8 September we ran the check our own timestamp proof page invites a reader to run. Download a day’s proof file, hand it to the OpenTimestamps reference client, and confirm the digest existed when we say it did. The client answered pending. It answered pending for every one of the twenty-six days we had sealed, including days whose Bitcoin blocks had confirmed three weeks earlier.

The record was never broken

The first thing to establish is what did not go wrong. Every day was anchored, on time, without a gap. We took the proof files, upgraded them against the calendar, and resolved each one to the Bitcoin block that contains it. The pattern is a block mined between 01:30 and 02:00 UTC on the morning after the day it seals.

Eight sampled days from a run of twenty-six, 13 August to 7 September, unbroken. Anyone can check these: take the proof file for a date, run the reference client against it, and read the block height it reports.

So what was wrong

A timestamp is created in two stages, and we were publishing the first one as though it were the second. When a digest is submitted, the calendar server returns a receipt: a promise to include that digest in the next batch it anchors. Some hours later the batch lands in a Bitcoin block, and the calendar can hand back a completed path from your digest all the way to that block header. Only the second artifact proves anything to a stranger. The first is a promise from a server you are being asked to trust.

Our daily seal wrote the receipt into the record and never went back for the completed path. Nothing upgraded it. So the file a reader downloaded was a calendar promise wearing the name of a Bitcoin proof, and the reference client said so, correctly, every time.

The claim on the page was true. The evidence attached to it did not demonstrate the claim. Those are different failures and the second one is easy to miss, because everything you can see from the inside looks right: the digests are correct, the roots are correct, the anchoring genuinely happened. The only way to catch it is to do what a reader does and verify from outside.

The upgrade, and how we checked it

Repairing this meant understanding the file format rather than trusting a library. A detached proof is a header, the file digest, a chain of operations, then an attestation. To upgrade it you walk the operations from the digest to work out the value the calendar was actually given, ask that calendar for the completed path, and splice the result in beside the pending attestation rather than over it.

Across all twenty-six files the operation chain used only three instructions: append, prepend and SHA-256. We wrote the walker to handle those, to recognise the two other operations it might meet, and to refuse outright on anything it does not understand. A proof it cannot read is left exactly as it is.

Then we checked the work the only way that means anything: we rebuilt every one of the twenty-six upgraded files with our own code and compared them byte for byte against what the reference client produces. Twenty-six of twenty-six matched exactly. Not equivalent, not valid according to us — identical bytes to the output of the tool everyone else would use to check us.

The repaired files went live at about 20:05 UTC on 8 September. As an illustration of the difference, the proof for 7 September went from 202 bytes to 1,169 bytes. The small file was a promise. The large one carries the block header.

Fixing it once is not fixing it

A backfill repairs history and nothing else. The seal that runs tonight will produce another calendar receipt, and by tomorrow the site would be back to publishing promises, just fresher ones. So the upgrade now runs on the same daily schedule as the seal itself, walking back over the last week and upgrading anything that has since confirmed.

It is written to be safe to run repeatedly. Any day already carrying a block attestation is skipped, so once it has caught up the whole pass costs a handful of reads. The week-long window means a calendar that was slow or unreachable yesterday gets another attempt rather than being abandoned. And it refuses in two situations: if a calendar answers without a block attestation it writes nothing, because replacing a good proof with a longer one that still proves nothing is worse than leaving it; and if it cannot parse a proof it skips it rather than guessing.

One caveat that belongs on the page

A day sealed within the last day or so is legitimately pending. The calendar has the commitment, the block that will confirm it has not been mined yet, and that is simply how the mechanism works. We have added that sentence to the proof page, because without it the next careful reader downloads today’s file, sees pending, and files exactly the finding you are reading about now — except theirs would be wrong.

Why we are publishing this

We sell the idea that a claim should be checkable by the person hearing it. A site that says it anchors to Bitcoin while handing you a file that cannot show a block is the same defect we report on other people’s sites: something asserted rather than demonstrated. Ours was smaller than most, because the underlying record really was sound. It was still ours.

It also lands the same way as the last one of these we wrote, about a scanner that reported a missing viewport tag which was there all along. Both were found by looking at our own output the way an outsider would, and neither would have surfaced from the inside. That is the argument for keeping a record at all, and it is the same argument behind the open dataset: a number nobody can re-derive is a number you are being asked to take on faith.

Related findings

Writing about this? Facts, live figures and marks — every number on that page is dated and traceable to a scan.

All findings · The dataset · How the dataset works