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

OpenTimestamps proof says pending? Upgrade the receipt

Every timestamp file this site served was the calendar's first receipt, not the finished Bitcoin proof. The anchoring was sound the whole time; the files did not show it.

On 8 September we ran the check our own proof page invites readers to run: download a day's timestamp file and check it with the OpenTimestamps reference client. It said pending for every one of the twenty-six days we had sealed, including days whose Bitcoin blocks had confirmed weeks earlier.

Was the record broken? #

No. Every day was anchored on time, without a gap. Once the files were upgraded, each one resolved to a Bitcoin block mined in the early hours of the following day. Anyone can check these with the reference client.

Eight sampled days from the run of twenty-six, 13 August to 7 September.

So what was wrong? #

A timestamp has two stages. The first is a receipt from the calendar server: a promise to include your digest in the next batch. The second, available once that batch is in a block, is the full path from your digest to the block. Only the second proves anything to someone who does not trust the calendar. We were publishing the first and never fetching the second. The claim on the page was true; the file attached to it could not show it.

What changed? #

All twenty-six files were upgraded and checked byte for byte against what the reference client produces: twenty-six of twenty-six identical. They went live on 8 September. The proof for 7 September grew from 202 bytes to 1,169, because the finished file carries the block header. New proofs are now upgraded once their block confirms. The proof page also now says that a day sealed within the last day or so is legitimately pending, because its block may not exist yet.

How do you check your own OpenTimestamps files? #

Run the reference client's verify command on the file. If it says pending well after the day has passed, run its upgrade command against the calendar and save the result; a finished proof is noticeably larger than a receipt. Keep the upgraded file, not the receipt. The broader point, the same one behind the viewport tag our check missed, is to verify your own output the way an outsider would. Our open dataset follows the same rule.

Questions this post answers

Why does my OpenTimestamps proof say pending?

Either the day is recent and its Bitcoin block has not been mined yet, or the file is still the calendar's receipt and has never been upgraded. Run the client's upgrade command to fetch the completed proof.

Is a pending OpenTimestamps receipt a proof?

No. It is a promise from the calendar server. Only the upgraded file, which links your digest to a Bitcoin block header, proves the timestamp to someone who does not trust the calendar.

Were CrawlCheck's seals ever missing a day?

No. Every sealed day in the run was anchored in a Bitcoin block mined the following morning. Only the files served to readers were incomplete.

How were the repaired files checked?

Each upgraded file was compared byte for byte with the output of the OpenTimestamps reference client, and all twenty-six matched exactly.

Is a proof for today expected to say pending?

Yes. A day sealed within roughly the last day may still be waiting for its block, and that is normal.

Related findings

Comments

Comments are read before they appear. Nothing is published automatically, and no account is needed.

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