Blockchain 1991

How to Time-Stamp a Digital Document

Stuart Haber & W. Scott Stornetta

Chain each record's hash to the one before, and no one can secretly change the past.

Choose your version

In depth · the introduction

How do you prove a digital file existed on a certain day, when anyone can quietly change the date on a computer — and even the time-stamping service might cheat?

The big idea

A paper document can be dated by the ink, the paper, the smudges — physical clues that are hard to fake after the fact. A digital file has none of that: copy it, edit it, change the clock, and there is no trace. Haber and Stornetta's insight was that you must time-stamp the data itself, not the medium it sits on.

Their trick: when you want a file stamped, you don't hand it over. You compute a short cryptographic fingerprint of it — a hash — and send only that. The service signs a little certificate saying when it received your fingerprint, and crucially it folds in a fingerprint of the certificate it issued just before yours. So every certificate is welded to the one before it. To fake the date on any single record, a forger would have to redo every record that came after — and other people already hold copies of those. The past becomes locked.

How it came about

In the late 1980s, Stuart Haber and Scott Stornetta were researchers at Bellcore in New Jersey. Stornetta had been worrying about a very practical problem: as science moved to electronic lab notebooks, how could a researcher ever prove what they knew, and when — for a patent fight, say — if the records were just editable files? The honest answer was that you couldn't, not reliably.

Haber, a cryptographer, saw that the fix had to come from mathematics, not from trusting some authority's clock. Together they built a scheme where the trust came from the structure itself. They published it in 1991, founded a company called Surety to sell it, and — to make their chain impossible to rewrite — began publishing a single summary fingerprint of all that week's stamps as a tiny advertisement in The New York Times. It has run every week since 1995.

Why it mattered

This is the hash chain — the structural heart of every blockchain. Years later, the anonymous author of Bitcoin built directly on this idea and cited Haber and Stornetta's papers. A blockchain is, at bottom, exactly their construction: each block hashes the one before, so the record of the past can't be quietly edited. Bitcoin added a way for strangers with no central authority to agree on the chain; but the tamper-evident spine was already here, in a 1991 cryptography paper that never mentions money at all.

A way to picture it

Think of a witnessed diary where each new entry must begin by copying a few words from the end of the previous entry, in that person's own handwriting. Now try to slip a forged page into the middle. Its ending won't match the words the next real page already copied — and that page's ending won't match the one after it, and so on. To fake one page, you'd have to rewrite the entire rest of the diary, and every witness is holding a photocopy. That chain of copied-forward fingerprints is exactly what Haber and Stornetta built with hashes.

Where it sits

This paper stands at a hinge in the history of trust. Before it, dating a record meant trusting a notary, a bank, or a government clock. Haber and Stornetta showed how a community could replace that trust with a self-checking structure. The line runs forward through Surety's newspaper hashes, through Git's tamper-evident commit history that programmers use daily, and through Bitcoin and the blockchains that followed — every one of them resting on this 1991 idea of chaining records with hashes.

The original document

Original source text

Abstract — time-stamp the data, not the medium

Stuart A. Haber, W. Scott Stornetta · Bellcore, 445 South Street, Morristown, N.J. · Journal of Cryptology 3 (1991): 99–111

The prospect of a world in which all text, audio, picture, and video documents are in digital form on easily modifiable media raises the issue of how to certify when a document was created or last changed.

The problem is to time-stamp the data, not the medium.

We propose computationally practical procedures for digital time-stamping of such documents so that it is infeasible for a user either to back-date or to forward-date his document, even with the collusion of a time-stamping service. Our procedures maintain complete privacy of the documents themselves, and require no record-keeping by the time-stamping service.

Introduction — certifying the date

§1 · Introduction

In many situations there is a need to certify the date a document was created or last modified.

[Paper documents can be dated by forensic signs in the medium; digital data has no such physical trace. A digital time-stamping scheme must instead bind the date to the bits of the document, while revealing nothing about the document's contents — the service should never need to see the document, only a hash of it.]

The linking solution (the hash chain)

§4 · A first solution — linking

A client computes a hash y = h(D) of the document D and sends only y to the time-stamping service (TSS). For the n-th request the TSS issues a signed certificate that records the sequence number, the time, the client's identifier, and the hash — together with linking information that ties this certificate to the previous one.

[In our notation the certificate is C(n) = (n, t(n), ID(n), y(n); L(n)), where the linking information L(n) = (t(n−1), ID(n−1), y(n−1), H(L(n−1))) carries a hash of the previous certificate's link. The hash values of documents submitted to the service are thereby chained together in a linear list into which nothing can feasibly be inserted or substituted, and from which nothing can feasibly be deleted.]

Anyone challenging the time on a certificate can ask its issuer to produce the certificates of the clients who came just before and just after; the temporal order is enforced by the chain itself, so the service cannot back-date a document without rewriting every certificate that followed.

Distributed trust (the random-witness solution)

§5 · A second solution — distributed trust

[In the random-witness solution, several members of the client pool must date and sign the hash value; their signatures form a composite certification that the time-stamp request was witnessed. These witnesses are chosen by a pseudorandom generator seeded with the hash of the document itself, which makes it infeasible to deliberately choose which clients will and will not act as witnesses — so no single service need be trusted.]

Stuart A. Haber · W. Scott Stornetta · Bellcore · 1991