Publishing your log's head hash, and why a hash chain alone isn't enough
By Dylan Wolpe
The short version
- A hash chain proves the internal consistency of the entries that exist. An event that was never written produces a chain that is perfectly valid and completely silent.
- Anchoring — publishing the chain's current head hash somewhere you do not control — freezes everything behind that point, so history older than the last anchor can no longer be rewritten without contradicting a third party's copy.
- Anchoring bounds the tampering window; it never proves completeness. Anyone selling it as proof of completeness is overselling it.
- Anchor frequency is a straight trade between exposure window and operational cost, and the right answer is set by how long you could tolerate an undetected rewrite.
We made a claim in passing a few weeks ago and then walked past it: neither a hash chain nor a blockchain can prove that something which happened was written down. It deserves more than a paragraph, because it is the limit that decides whether your audit trail survives a determined challenge.
The gap
A hash chain gives you a strong guarantee with a precise shape. Each entry commits to the one before it, so altering, inserting or deleting any entry breaks recomputation from that point forward. That covers three of the four things you want.
| Attack | Caught by a hash chain? |
|---|---|
| Edit an existing entry | Yes — chain breaks at that entry |
| Delete an entry | Yes |
| Insert an entry into the past | Yes |
| Never write the entry at all | No |
| Rebuild the whole chain from scratch | No |
The last two are the same problem wearing different clothes. If you control the log and the code that writes it, you can decline to record something, or — more thoroughly — regenerate the entire chain from a doctored history. Every hash will be internally consistent. Every verification will pass. The chain attests to nothing except that whoever built it built it consistently.
A hash chain proves nobody edited the story after it was written. It cannot prove the story was written honestly the first time.
Anchoring
The fix is to stop being the only holder of the chain’s state. Periodically take the current head hash and publish it somewhere outside your control:
Mon 09:00 ... -> h1247 -> anchor h1247 with counterparty Tue 09:00 ... -> h1602 -> anchor h1602 Wed 09:00 ... -> h1955 -> anchor h1955 Attempt to rewrite entry 1300 on Wednesday: recomputed head != h1602, which the counterparty holds and dated. The rewrite is now provable, not merely suspected.
This is the mechanism behind Certificate Transparency and behind every notarial practice going back centuries. It does not require a blockchain, a token or a network. It requires one hash and someone who is not you.
What to anchor to
The options differ in how independent they really are, which is the only property that matters:
- Your auditor or outside counsel. Cheapest and often the most useful in practice, because they are the party who will later be asked. An emailed head hash with a timestamp, filed, is worth more than it sounds.
- A counterparty. If the log records a bilateral relationship, the other side has a natural interest in holding a copy and no interest in helping you rewrite it.
- An RFC 3161 timestamping authority. Standardised, cheap, and produces a token that verifies without any relationship to the issuer.
- A public medium. Anything sufficiently public and archived. Strong independence; the practical cost is that you are publishing a value on a fixed schedule forever, and the schedule itself becomes visible.
Multiple anchors are better than one and are nearly free. The question a challenger will ask is “could the anchor holder have colluded?”, and two unrelated holders answer it far better than one.
How often
Anchoring does not eliminate the risk of rewriting; it caps it. Everything before the last anchor is frozen, and everything after it is exactly as trustworthy as your controls. So the interval is your exposure window, and the honest way to choose it is to ask how long an undetected rewrite could go unnoticed before it stopped mattering.
| Interval | Exposure window | Reasonable for |
|---|---|---|
| Per entry | None | Low-volume, very high-stakes records |
| Hourly | Up to 1 hour | Financial and trading logs |
| Daily | Up to 24 hours | Most operational and access logs |
| Monthly | Up to a month | Low-risk archival |
What this means in practice
If you already run an append-only hash-chained log, you are most of the way there and the remaining step is administrative rather than technical. Take the head, send it somewhere, keep the receipt. If you are evaluating vendors, the useful question is not “is it immutable” — everyone says yes — but “what is the largest window in which you could rewrite history and I would not be able to prove it?” A vendor who has thought about anchoring will give you a number. A vendor who has not will give you an adjective.
The AT-1 Ledger produces a head hash that is meant to be exported and handed to someone else; the verifier runs standalone, so whoever holds your anchor can check it without us and without a licence. That combination — cheap anchoring plus independent verification — is what turns a log from a record you keep into evidence someone else can rely on.