Breaking the chain

• verify. Recompute every block's hash and compare every block's prev against the block above. Returns ok, problems and firstBad.
• problem. One entry in that list: an index and a kind.
• kind hash. The block's stored hash does not match a fresh hash of its own fields.
• kind link. The block's prev does not match the hash of the block above it.
• firstBad. The index of the first problem found, or nothing when there are none.
• tamper. Change one block's data and leave every stored hash alone, which is what editing the database does.
• hashBlock. Rehash one block from its own fields. The attacker's repair tool, and the auditor's.
• reforge. Redo a block and every block after it, so the register is internally consistent again.

A verifier that returns true or false tells you a register is broken and leaves you to find out how. This one returns the index of every failure alongside a kind, and the kind is what turns a failed check into an account of what happened. Two registers can both fail with exactly one problem and be the result of completely different actions.

So the habit worth building is to read the problem list before the boolean. If you only ever look at ok, you have built a smoke alarm with no address on it.

The link comparison needs a block above, and block 0 has none, so the walk skips it there. Its previous hash field holds 64 zero characters that nothing computed and nothing can check, which means block 0 can be rehashed and it will be internally consistent whatever it says.

The consequence is worth stating before the attack begins. An attacker who rewrites from block 0 forwards is not detected by anything in this report, because there is no earlier value for the report to disagree with. What catches that attacker is somebody else holding a copy, which is a different mechanism entirely.

One camp says a verifier should stop at the first failure. After the first mismatch nothing downstream is trustworthy, a long list of consequent problems buries the one that matters, and an operator who is shown forty red rows will read none of them. On that view firstBad is the answer and the rest of the list is noise dressed as thoroughness.

The other camp says the pattern of problems is the evidence. One hash mismatch, one link mismatch, a hash and a link together, or a run of them down the register are all different situations, and truncating at the first one throws the forensics away to save a reader some scrolling. On that view a verifier that stops early has decided for you what the incident was.

The engine on this page declines to choose: it returns the whole list and the first index as separate fields, so the same call serves the operator and the investigator. That is a reasonable answer and it is not a free one, because a register with a million blocks and a systematic fault produces a list nobody can hold, and then somebody has to decide what to truncate after all.

Press the repair button repeatedly and the report alternates. A hash mismatch at some block, then a link mismatch at the next one, then a hash mismatch there, and so on. Each repair satisfies the check it was aimed at and breaks the next one, because every fix changes a value that a later block already copied.

The alternation stops in one place only, which is the last block. Nothing copies the last block's hash, so there is no later check left to break. That is the mechanical reason a rewrite has to run all the way to the end of the register, and the reason the position of the edit, rather than its size, decides the workload.

The tamper call changes one block's data field and copies every other field across untouched, stored hash included. That is not a weakened attack, it is the realistic one: somebody with database access edits a row, and the row does not know it is part of a chain. The stored hash sits there as a witness to what the row said when it was written.

This is also why a register whose hashes are recomputed on read is worth nothing. If the verifier rehashes a block and stores the result, every edit repairs itself and the first check can never fail. The stored hash has to be the old one for the comparison to mean anything.

The edit used here turns one word of block 2 into capitals and changes nothing else about the length or the shape of the line. That is deliberate. A reader scanning the register sees almost the same sentence, and every check still fails as hard as it would for a rewritten paragraph, because the digest has no notion of how large a change is.

It follows that there is no such thing as a small edit to hash protected data. A typo correction and a fabricated inspection result produce failures of identical severity, which is convenient for detection and inconvenient for anybody who has to run a register where legitimate corrections happen.

Somebody hands you a report saying one problem, index 4, kind link. Without seeing the register you can already say that block 3 was rebuilt, that whoever did it did not continue past it, and that blocks 0 to 2 were left alone. You can also say that block 3's own hash is consistent with block 3's current contents, because otherwise there would be a hash problem at 3 as well.

What you cannot say is what block 3 now contains, whether the change was malicious, or whether it was a botched migration. The report is about structure. Attributing intent to it is the commonest way these findings get misreported upwards.

Both checks run at every index, so a single block can contribute a hash problem and a link problem in the same pass, and several blocks can contribute their own. A list with many entries usually means something structural rather than something surgical: a failed load, a truncated copy, two writers with different field orders.

A list with exactly one entry is the interesting case, because somebody was careful and stopped one step too early. That is the shape both stages above produce, and it is the shape worth recognising on sight.

Verification compares the register with itself. It has no second opinion, so anything consistently applied across the whole register is invisible to it: an entry that was never written, a register rebuilt from block 0, a set of timestamps that were all wrong at the moment of writing.

This is why the useful question after a clean report is not whether the hashes match but who else holds a copy and when they last compared. A clean report from a single copy is a statement about one file, and treating it as a statement about history is the mistake the whole subject invites.

Reforging from block 5 redoes one block. From block 2 it redoes four. The workload is the distance from the edit to the end of the register and has nothing to do with how much text was changed, so the oldest entries are the most expensive to alter and the newest are nearly free.

That ordering is useful and it is also the opposite of what most disputes need. Arguments are usually about something recorded recently, and recent entries sit at the cheap end. A register that has only just written the entry you are relying on is protecting it with the least work it will ever have.

The elapsed figure is measured in your browser on this run, on whatever machine you are holding, and it will differ between two presses on the same laptop. It is quoted here as an order of magnitude and nothing finer, because the point survives any reasonable variation: a handful of hash computations completes faster than a person can notice.

Do not carry that number anywhere. Session 4 measures attempts instead, which is the quantity that does not depend on the machine, and it does it over many runs rather than one.

Nothing inside the register does. What stops it is everything outside: somebody else holding a copy of the old version, a published root that was recorded somewhere the attacker does not control, an append only store, backups nobody with write access can reach.

All of those are ordinary operational controls, and they are doing the work that people often attribute to the chain. The structure contributes one thing, which is that comparing two copies is a one line check rather than a reconciliation project. That is worth having and it is not the same as making the register hard to change.