Bitcoin document timestamping: what should a verifier be able to check independe

[juanpabloabadiamedina]

I'm a software developer from Colombia interested in using Bitcoin to make document verification easier for small organizations.

Here's the scenario: an organization keeps a PDF private but wants to be able to show later that the exact file already existed when a specific Bitcoin block was mined. The idea is to hash the PDF locally, anchor a commitment to Bitcoin, and keep the proof alongside the original file.

I'm looking at OpenTimestamps and have two practical questions:

1. What should the organization archive today so that an independent verifier can check the proof years later, even if the original calendar server is gone?
2. Once the proof is complete, what trade-offs do you see between verifying it with your own Bitcoin node and using a public verification service?

If you've built or maintained a workflow like this, I'd be interested in what you learned about storing and verifying proofs over time.

[ABCbits]

1. What should the organization archive today so that an independent verifier can check the proof years later, even if the original calendar server is gone?

On Bitcoin blockchain side, just one Bitcoin transaction. The organization should compute hash of each file, then get merkle tree based on those and use OpenTimestamp to store the merkle tree. Outside Bitcoin blockchain, they need to store all file hash and information how the merkle tree is created. Peter Todd write an interesting article about it, How OpenTimestamps 'Carbon Dated' (almost) The Entire Internet With One Bitcoin Transaction.

[Stefen003]

To add to ABCbits' answer, a few practical points for a long-lived OTS workflow:

What to archive

• The exact original bytes of the PDF. Re-saving or re-exporting it (even "no changes") will change the SHA256 and the proof won't match anymore.
• The upgraded .ots file. Right after stamping, the .ots only contains a "pending" attestation that depends on the calendar server. Once the calendar's transaction is confirmed, run ots upgrade file.pdf.ots. That embeds the full merkle path down to the Bitcoin block header, so the calendar is no longer needed at all. Check the proof shows a BitcoinBlockHeaderAttestation (e.g. with ots info) before you consider it finished.
• Optionally a small text note with the block height, hash algorithm and client/spec version, so a verifier many years later knows what format they are looking at.

Own node vs public verification service
With your own node, ots verify checks the merkle root against a block header your node validated itself, so it's fully trustless. A public verifier/explorer is fine for convenience, but you are trusting them to tell you the correct header. Headers are only 80 bytes each though, so even an SPV-style header chain gets you most of the way without trusting a third party.

Two caveats worth telling the organization:

• Block timestamps are only loosely bound (must be greater than the median of the previous 11 blocks and not more than ~2h ahead of network-adjusted time). So the proof means "this file existed before roughly this time", accurate to a few hours, not to the minute.
• Privacy: the calendars only ever see a hash, and the OTS client adds a per-file nonce before submitting, so a calendar operator can't confirm a guessed document from the hash.