A fingerprint says whether a text has changed; a clock no one controls lets one establish when this text existed; a stable signature says it comes from the same author. Put together, these three things do not abolish trust: they shift it from whoever publishes to what anyone can check

An implicit promise

Whoever publishes something makes, without saying so, a small promise: that the text, tomorrow, will still be what it is today, or that at least one will be able to tell if it has changed. The usual way to keep it is trust. We trust the site, the archive, the publication. But trust is exactly what we want to remove here, because asking "take my word for it" is the opposite of letting someone check.

The use case is minimal: someone publishes a text online, a reader finds it useful and quotes it by link; one would like whoever follows that link to be able to easily notice whether the content has changed in the meantime. Whether this specific case matters or not, it seemed a good exercise to build a mechanism that delegates trust as little as possible, with tools that already exist, promising nothing surprising and without reinventing the wheel.

Worth saying right away: this is a use case, not a showcase of buzzwords. Hashes, timestamps, Bitcoin do not appear here to sound impressive, but because they answer a concrete need, however small. The example serves to show exactly this: that real cases exist, not to flaunt the terms that name them. What follows is the story of how, one honest question after another, the final form was reached, and of where, with equal honesty, the mechanism stops.

The fingerprint

The first tool is a digital fingerprint, a hash: the result of a function that takes a text, of any length, and returns a short string of fixed size. Three properties make it useful. It is deterministic: the same text always gives the same fingerprint. It is sensitive: changing a single comma produces an entirely different fingerprint, with no resemblance to the previous one. And it is one-way: there is no going back from the fingerprint to the text, but comparing two fingerprints is immediate.

Hence the first move. Publishing a text's fingerprint next to it turns "trust that it hasn't changed" into "check that it hasn't changed". Whoever kept the text recomputes its fingerprint and compares it with the declared one: if they match, it is byte-for-byte identical; if they differ, something has changed. For this to work for anyone, the fingerprint must be public and reproducible, computed with a documented method and with no secret ingredients.

"But couldn't anyone do it themselves?"

And here comes the first awkward question. To notice that a text has changed, strictly speaking, whoever publishes need do nothing: an attentive reader could save the text at every visit and compare it again on their own, or compute its fingerprint independently. If so, what does publishing the hash really add?

It adds three things, and none is "detecting the change". The first: it defines what the content is. A fingerprint computed on one's own is fragile, because it depends on what was saved: the HTML? the text with or without menus, spaces, layout? Publishing the fingerprint fixes a precise object, this exact sequence of bytes, so that a change of template is not mistaken for a change of substance. The second: it makes the comparison reproducible with a universal tool, not with custom code. The third: it reduces the diligence to copying a short string, light enough to sit in a citation note. The value, here, is not discovering the change: it is making it well-defined, reproducible and cheap.

"And proving it to someone else?"

Convincing oneself is one thing, proving it to someone is another. And here the fingerprint alone is not enough: to prove to a third party that a text has changed, one must hold the preimage, the exact text that produces that hash. Whoever keeps it at the moment of quoting can later show "here is the text, recompute its hash, and you see that today whoever published it declares a different one". The decisive proof, it must be said, is the one the reader kept: whoever publishes makes it easy and standard, does not replace it.

And there is a limit worth stating right away, because no cryptographic trick overcomes it: whoever publishes cannot prove, alone, to have served that very text at that address in the past. The published fingerprint is a claim in the present, "this is my content, here is its fingerprint". That at that URL, on that date, that text was really there, is attested by evidence someone captured, or by a third-party archive, not by whoever publishes looking at themselves in the mirror. There remains, though, a more modest reason to trust anyway: a fingerprint that does not match the content shown can be exposed instantly by anyone, so publishing a false one does not pay. It is not proof of good faith, but an aligned incentive: trust reduced to a checkable fact.

A clock is missing

The biggest limit remains. The fingerprint says whether a text has changed; it does not say when it existed. A fingerprint, on its own, has no date. Anyone can compute today the fingerprint of a text and claim it dates back a year: nothing, in the fingerprint, disproves it. A clock is needed. But not just any clock, because the delicate point is exactly this: it must be a clock whose hands no one can turn back, not whoever publishes, not whoever runs it.

A timestamping authority, a trusted party that signs "I saw this fingerprint on this date", would solve the problem by moving it: trust would return, this time in that authority, which could err, shut down, or be persuaded to backdate. Independent verification asks for something more inconvenient: a clock that belongs to no one.

Distributed does not mean decentralized

Here it is worth pausing on a distinction usually confused, and that is the heart of the matter. A distributed system is made of many copies: the same data lives on many computers. But "many copies" says nothing about who is in charge. A bank keeps its own ledger replicated across many data centers: utterly distributed, yet perfectly centralized, because a single entity can rewrite it. Redundancy protects from failures, not from the authority that controls it.

Decentralized is another thing: it means that no one, alone, can rewrite history. It is not a question of the number of copies, but of who has the power to change them all. It is in this sense that Bitcoin is more decentralized than distributed: its strength lies not in having many copies of the ledger, which centralized systems have too, but in the fact that rewriting the past would require redoing all the work accumulated on top of it, racing against the whole network. It is a clock whose hands, once they have passed, are nailed down not by a promise but by a cost.

Why Bitcoin in particular

In a chain that keeps time by emitting a block roughly every ten minutes, that cost has a name: proof-of-work. (Those ten minutes are not arbitrary: they are a compromise, long enough for a block to propagate across the whole network before another appears, so the chain converges instead of forking continually, and short enough not to make a confirmation wait too long.) Adding a block requires spending energy to solve a hard problem; each block includes the fingerprint of the previous one, so the blocks chain together. Modifying an old block would mean redoing its proof and that of all the following blocks, faster than the network adds new ones. The more time and work accumulate on top of a given page of the ledger, the more impossible that page becomes to rewrite. (Why this suffices to make strangers who do not trust each other agree, the classic Byzantine generals problem, is here taken as given: its result is used without re-proving it.)

This is the property the clock needs. Not "whoever publishes declares it is old", but "it existed before a block that cost everyone an amount of work no one can undo after the fact". The anchoring to time stops depending on trust in whoever publishes and starts depending on a chain that whoever publishes does not control.

How OpenTimestamps does it

A practical problem remains: putting every document inside Bitcoin's chain would be costly, slow, and would publish the text. OpenTimestamps gets around it with an elegant idea: onto the chain goes neither the document nor even its fingerprint, but a single number that summarizes millions of fingerprints together.

The mechanism is a Merkle tree. Many fingerprints are taken, combined in pairs by computing the fingerprint of each pair, then those results are combined in pairs, and so on going up, until a single fingerprint remains at the top: the root. The root depends on all the leaves: changing any one of them changes the root. Of the whole tree, only the root ends up in a Bitcoin transaction. The .ots file that accompanies a text is the path from its fingerprint up to that root: the few neighboring fingerprints needed to climb, step by step, from leaf to top. To verify, one recomputes the path, obtains the root, and checks that this root really ended up in a block.

Hence three consequences. The timestamp is immediate to request, slow to confirm: as soon as it is requested, a calendar server takes the fingerprint and gives a receipt at once, but it is still pending: it becomes full only when the root enters a confirmed block, usually after a few hours. It scales almost for free: a single anchor on the chain marks, in one go, all the fingerprints of that round, be they a thousand or a million. And to verify, Bitcoin is enough: once complete, the .ots contains the whole path up to the block, and the calendar servers can even disappear, because one checks against the chain, not against them.

The two sides of the window

OpenTimestamps, however, gives only one side of the clock: it proves that the content existed no later than the block that confirms it. It is an upper bound. On its own it leaves the opposite question open: and before, since when?

The second side is obtained with the same chain, used in reverse. In the canonical text, inside the fingerprint, one places the anchor: the height and hash of a recent Bitcoin block, chosen at the moment of sealing. A block's hash is unpredictable until the block has been mined: no one can write it in advance. Finding it inside the fingerprint therefore proves that the content was sealed no earlier than that block: a lower bound. Put together, the two anchors close the content inside a window: born after the anchor block, existing before the timestamp block. Not a declaration, but two ends supported by the chain. (It is a technique decades old, Haber–Stornetta linking: tying a datum to something that could not be known before.)

Honesty about the window: the ends come from the blocks' timestamps, so the "certainly" is about order relative to the block, not about an instant to the second; the window has a width. What also contributes to that width is a deliberate margin: neither the anchor block nor the timestamp block is considered settled at the instant it is mined, but only once enough work has piled on top to make rewriting it unreasonable. It is the same threshold, measured in ten-minute blocks, that is held reasonable for calling the chain "immutable"; and it is why the two sides of the window, backward and forward, do not narrow down to the instant. And for a text sealed after its first publication, the lower bound starts from the moment of sealing, not from the original date.

"And who produced it?"

At this point one knows whether a text has changed and when it existed. The who is missing. And here the utmost honesty is needed, because it is the point where the least is promised. A timestamp does not prove authorship: anyone can timestamp any text, even a copied one. Establishing who had an idea first is not, and is not meant to be, the purpose of this mechanism: the verifiability of the claim matters more.

There is, though, a more modest and honest who that can be added: not the legal identity, but a consistent identity. Every verifiable text is signed with a stable key, always the same (in practice, with minisign). The signature does not say who the author is in the real world; it says that a version comes from the holder of that key, and makes it hard for a stranger to impersonate the author or rewrite their history, because they do not have the key. If the key is itself placed in time, with the same windowed clock as the contents, one obtains the closest thing to an authorship it is honest to claim: "the holder of this key had committed to this text before a certain block".

Everything rests on one condition: knowing that the key is really the author's. For this the public key is spread early and in several places, and tied to the domain by two independent paths, a file served over HTTPS and a record in the DNS, so that compromising just one is not enough to replace it silently. And a small identity declaration ties it, in one stroke, to the name, the domain, the published contents and a proven window of time. The key pair too, this way, has a date, not just a word.

"And the order of the versions?"

One last question, and a small addition. A text can change several times: how to trust the order in which whoever publishes declares its versions? Without asking for trust, one makes each version, in its canonical text, carry the fingerprint of the previous one: a chain, each link tied to what came before. Reordering or altering a recorded version breaks the arithmetic. It is, again, Haber–Stornetta linking, this time applied to the document's history.

It must be said small, because it promises little: the chain makes alteration and reordering of what has been recorded and captured detectable, but does not prove completeness. A version no one ever captured remains, in principle, omittable. A limit of nature, not of implementation.

What it proves, and what it does not

It is worth, then, lining up what the mechanism does not demonstrate, because this is where its honesty is measured. Not real authorship: it proves the existence of a text within a window, not who wrote it. Not the exact instant of creation, but an interval. Not that whoever publishes served that text at that URL in the past. Not the completeness of the list of versions. And not who controls the key in the real world: the signature guarantees a consistent author, and that the key is really the author's must, in the end, be believed, however much the tie to the domain makes it hard to forge.

These are limits, not flaws. What remains, within those bounds, is solid and checkable by anyone: that a certain text, in that exact form, existed within a certain window of time, signed by a stable identity, and whether since then it has changed or not. Trust does not vanish; it narrows to what is irreducibly the word of whoever publishes, the completeness of the list and the ultimate tie between key and person, while everything else is verifiable against universal tools and a chain no one controls.

Shifting trust, not asking for it

Lined up, the tools do one single thing: they shift verification from trust to checking. The fingerprint removes the need to believe that a text has not changed. The timestamp and the anchor remove the need to believe whoever declares its date, because they rest it on a ledger that whoever publishes does not own. The signature removes the need to believe on someone's word that a version comes from the same author. What remains on whoever publishes is no longer "trust me", but "here are the tools, check".

In practice, checking is a matter of a few steps: re-download the text in its canonical form, recompute its fingerprint, verify the .ots file against the Bitcoin chain and the signature against the public key. If the sums add up, that text is the one, in that window of time, from that key.

None of these tools is new: hashes, Merkle trees, proof-of-work, timestamps, signatures. The only claim is to have put them together in a straightforward way, for a purpose that has nothing to do with the price of coins: using Bitcoin's time chain as a public clock. It is an idea that holds beyond this use case: verifiability matters more than the claim. It is not about asserting "I wrote it, first"; it is about anyone being able to ascertain, for themselves, what a text said, since when, and that it has not changed. Here is why it works, and for which questions, one honest one after another, it was reached this way.

References

A real case, verifiable step by step by anyone, is one of those concrete cases: you can see one applied at liberlume.com/en/verify.