Bitcoin-anchored file timestamping

"Bitcoin-anchored file timestamping" is the umbrella term for a small family of techniques that bind a file's contents to a specific moment in Bitcoin's transaction history. The dominant protocol is OpenTimestamps. The technique is older than most cryptocurrency speculation, and the underlying idea — Merkle trees plus a public ledger — was the breakthrough behind Bitcoin itself.

The walk from your file to a Bitcoin block

Step one happens entirely on your computer. The browser computes a SHA-256 hash of the file. SHA-256 is a fixed-size fingerprint: any input, no matter how large, produces a 32-byte output. Change a single byte of input and the output changes completely. The hash reveals nothing about the file's contents.

Step two: that 32-byte hash is submitted to one or more calendar servers. A calendar is just a publicly-listed server that collects user hashes and, on a regular cadence, combines them into a Merkle tree. The Merkle root — a single 32-byte value summarizing thousands of user submissions — is what eventually reaches Bitcoin.

Step three: the calendar broadcasts a Bitcoin transaction whose OP_RETURN output contains that Merkle root. OP_RETURN is the standard way to embed a small payload in a Bitcoin transaction without creating spendable outputs. The transaction is mined into a block, and the block's timestamp becomes the timestamp for every hash inside the Merkle tree — including yours.

Step four: you receive a small proof file. It contains your hash, the Merkle path from your hash up to the Merkle root, and a reference to the Bitcoin transaction that committed that root. Anyone with this proof file and the original input file can walk the Merkle path, recompute the root, look up the Bitcoin transaction, and confirm the block time.

Why the per-file cost is effectively zero

At Bitcoin's current fee rates, a single transaction costs anywhere from a few cents to a few dollars depending on mempool congestion. If each user paid for their own transaction, file timestamping would be uneconomic for anyone but enterprises. The Merkle-batching design amortizes one transaction across thousands or millions of user hashes. Calendar operators absorb the fee.

This is also why Orphograph doesn't charge cryptographic fees that scale with your usage. Our pricing reflects the cost of running a receipt-management UI, sending emails, and providing a hosted verifier — not per-anchor blockchain economics.

Five calendars instead of one

Orphograph submits each hash to five independent OpenTimestamps calendars rather than relying on a single operator. If one calendar vanishes or refuses to serve the upgrade path later, the other four remain. Your receipt only needs one surviving calendar to verify successfully against Bitcoin — the redundancy is purely a hedge against operator failure.

What you get back

The artifact is a JSON receipt plus five small binary .ots files. Total disk footprint: roughly 3 KB. Save them next to the original file. To verify later, point any OpenTimestamps-compatible client — including the open-source verify_cli.py shipped with Orphograph — at the receipt. It will walk the Merkle path, fetch the Bitcoin block headers it needs, and confirm the date.

FAQ