What verification cannot see.

Every construction in the previous three papers checks something that was handed to it. None of them can say anything about what was not. A chain with its last records removed verifies perfectly — every hash, every link, every signature — and that is not a defect to be patched but a boundary to be understood, because what lies beyond it needs a party other than you.

§1The prefix problem

Take an honest chain of twelve records, built exactly as Paper 003 describes. Delete the last two. Hand over the remaining ten.

Every record recomputes to its recorded hash. Every link matches its predecessor. Every signature is genuine — they were never forged, merely not included. A verifier examines the ten records it was given, finds nothing wrong, and reports an intact chain. It is right: those ten records are an intact chain. They are simply an intact chain of a shorter history than the one that existed.

This is worth dwelling on because it is the limit most often glossed. A system can be described accurately as detecting edits, reordering, insertion and forgery, and still be silent about the simplest attack of all: producing less.

§2The commitment, and why it must be held elsewhere

The escape is to move one small piece of information outside the system. After writing record n, publish a commitment to the state of the chain at that moment — the position, the count, and the link value that record produced:

commitment = { seq: 12, count: 12, link: 262d5c40d754777f… }

An examining party who obtained that commitment earlier can now detect the truncation: ten records do not satisfy a commitment covering twelve. The commitment is small enough to write in a file note, mail to an auditor, or print.

Two properties of it matter more than the format:

• It must be obtained earlier. A commitment handed over at the same time as the records is worthless — the party who trimmed the records would trim the commitment to match. Its entire value is that it was fixed before the dispute existed.
• It must be held by someone else. A commitment stored beside the records it protects is protected by nothing. If both live in the same store, the adversary of Paper 001 reaches both.

That second requirement is the crack through which everything in §5 enters, and it is the reason this paper does not end here.

§3A commitment cannot validate a slice

Here the design admits a subtle and consequential error, which is worth setting out because it looks like a feature.

Disclosure is usually partial in two dimensions. Paper 002 handled one — withholding fields within a record. The other is range: a party is asked for last quarter's records, not all of them. That is legitimate and it is the normal case. To verify a range on its own, a recipient needs the link value that the record immediately before the range produced — hand it over and records 400 to 450 can be checked without ever seeing records 1 to 399.

Now combine that with the commitment from §2, and the trap opens.

the auditor holds     commitment { seq 10, count 10, link 4b352aa9… }
the discloser produces  records 5…14  +  priorLink of record 4

records 1–4 are silently absent
every signature valid · every link intact · verdict: VERIFIED, exit 0

§4"Why not a blockchain?"

The question arrives in every discussion of this material, and it deserves a real answer rather than a dismissal, because the instinct behind it is correct.

What the question is reaching for is a structure where history cannot be quietly rewritten and where no single party decides what the history was. That is a legitimate requirement. But a distributed ledger achieves it by an expensive route — replicating all data to mutually distrusting parties and running consensus to agree an order — and the properties actually needed here are obtainable from a much older and smaller construction.

That construction is an append-only transparency log: the RFC 6962 tree of Paper 002, with its two proofs.^[1] No consensus, no token, no network that must outlive the evidence, and — importantly for records that are commercially sensitive — no requirement to publish the data itself, only roots.

So the honest answer to the question is neither "we use a blockchain" nor "you don't need one". It is: two of the three properties come from a 1979 data structure standardised in 2013 and deployed in every browser's certificate ecosystem; the third needs a witness, and a distributed ledger is one — expensive — way of hiring several.

§5The gap that remains: split view

Everything so far is checkable by a recipient against material the operator provides. That leaves one attack untouched, and it is the honest limit of a self-hosted log:

No amount of internal cryptography closes this, and it is worth being blunt: a log that is published, verified and audited entirely by its operator has not eliminated the need to trust the operator; it has made that trust precise and narrow, which is progress, but it has not removed it.

Closing it requires a party other than the operator to observe a root and be able to testify to it later. Two mechanisms do this, and they are complementary rather than alternative:

• Gossip between recipients. If two parties who were shown different roots ever compare them, the split is exposed by a failing consistency proof. This costs nothing to enable and works only if recipients actually compare — which, in practice, they rarely do.
• A witness who countersigns. A third party that observes each published root and signs a statement to that effect. Now producing a second history requires the witness's participation, which moves the attack from "quietly maintain two databases" to "conspire with an external party who has no reason to help you".

§6Time is a separate problem, and it needs the same kind of witness

A signature proves authorship. It says nothing about when — the signer chooses the clock, and the adversary of Paper 001 has the key. Establishing time therefore has the same structure as establishing a single view: it requires someone with no stake in the answer.

The standard mechanism is a timestamp token over a digest, obtained from a timestamping authority under RFC 3161.^[2] The authority signs a statement binding a hash to a time, without ever seeing the data behind the hash. Applied to a published root, it converts "the operator asserts this history existed on Tuesday" into "an independent authority attested to this root on Tuesday" — the same witness function as §5, obtained from an established supply of them.

Within the European framework, this is where a distinction is worth stating precisely, because it is routinely blurred in marketing material. Regulation (EU) No 910/2014 as amended treats electronic timestamps at two levels:^[3]

An unqualified timestamp — from a free public authority, say — obtains Article 41(1) and nothing beyond it. It is genuinely useful as an engineering control and it is not the legal instrument that 41(2) describes. Describing a system as offering "eIDAS-compliant timestamping" without saying which of those two it means is, at best, imprecise.

§7An honest ledger of what is open

Collecting the limits from all four papers in one place, because a reader deciding whether to rely on this class of construction is entitled to them together rather than scattered:

1. Omission is invisible without an external commitment, and the commitment is only worth what the independence of its holder is worth.
2. Split view is not closed by internal cryptography. It needs a witness, gossip between recipients, or both.
3. Time is not established by a signature. It needs an independent authority, and the legal weight of that authority varies by whether it is qualified in the relevant sense.
4. None of this speaks to truth. A verified record of a false statement remains a false statement, verified.
5. A construction is only as good as its verifier, and verifiers fail in ways constructions do not — as Paper 003 §9 and §3 above both show, and as anyone shipping one should assume of their own.

None of these are reasons not to build the thing. They are the reasons to describe it accurately: a party evaluating evidence infrastructure is, by disposition, someone who will find the boundary eventually. It is materially better for them to find it in your documentation than in cross-examination.