Building the chain

• Block. One record: index, timestamp, data, prev, nonce, hash.
• prev. The field holding the previous block's hash, all 64 characters of it.
• Genesis block. Block 0, whose prev is 64 zero characters by convention.
• Block hash. The digest of the whole assembled block. Not the digest of the entry text.
• Nonce. A field that can change without changing what the block says. Idle at difficulty 0, and the subject of session 4.
• Difficulty. How many leading zeros a block hash must have. Zero for the Harbourgate register.
• Reproducible. Rebuilt from the same entries, the register gives the same six hashes, because the timestamps are fixed.
• verify. Recompute every hash and check every link. Returns ok on the untampered register, and session 3 breaks it.

If only the entry text were hashed, two identical entries would produce identical digests and could be swapped, duplicated or reordered without leaving a mark. Putting the index in the digest fixes the block to a position. Putting the timestamp in fixes it to a moment. Putting the previous hash in fixes it to a history.

So a block hash is a statement about five things at once, and any claim you make from a matching hash inherits all five. That is stronger than people expect and still narrower than the word immutable suggests.

Every block in the register carries a nonce of 0, and at difficulty 0 nothing ever changes it. It is in the record because a block needs one field that can be varied freely without altering what the block says, so that a hash can be searched for rather than merely computed.

Press the nonce button in the box above and watch the digest move completely for a change from 0 to 1 that alters nothing anybody would read. Session 4 turns that uselessness into the entire cost model of mining.

The five fields are joined in a fixed order with a separator before they are hashed. Any other order, or any other separator, produces different digests for the same register, which would still be perfectly self consistent and would disagree with every other implementation.

That is the unglamorous reason serialisation formats get specified to the byte in real systems. A verifier and a writer that disagree about field order do not fail loudly. They just never agree on a hash, and the register looks permanently tampered with.

Some registers do exactly that. They put a newspaper headline, a court filing reference or a published document digest into the first block, so the start of the register can be dated from outside the system. It is a genuinely useful trick, and it does not change the structure at all, because that value still enters the block as data rather than as a verified link.

The zeros are the honest default. They announce that nothing precedes this block and make no claim at all about when it was written or by whom, which keeps the unanswered question visible instead of dressing it up.

Verification walks the register recomputing each block's hash from its own fields, and comparing each block's prev field against the hash of the block above. Block 0 has no block above it, so the link check simply does not run there, and only the hash check applies.

That asymmetry is worth holding on to. Block 0 is the one block whose position in history rests on nothing inside the register, which is why an attacker who can replace the whole register from block 0 onwards is a different threat from the one in session 3, and a much harder one to reason about.

One camp holds that batching entries into blocks is an accident of network economics. If every entry simply carried the hash of the entry before it, you would get the same tamper evidence with less machinery, no block assembly, no batching delay, and a structure a reader can hold in their head. On this view the block is an optimisation that leaked into the conceptual model and then got taught as though it were the idea.

The other camp holds that the block is the unit of agreement, and that without it there is nothing to agree on. A batch is what participants vote on, what work is attached to, and what gets accepted or rejected as a whole. Remove the block and the tamper evidence survives but the mechanism for many parties converging on one history does not.

Both are right about different things, which is why the argument survives. Notice that a single organisation keeping one register has no need of the second camp's answer, and that is the shape most internal projects actually have.

The timestamps are set by the loop, starting at 1758000000 and advancing 600 seconds per block, so rebuilding the register from the same six entries produces the same six hashes every time. That is what lets a number in a diagram be checked against a number on your screen, and it is the only reason these pages can quote hashes at all.

A real register reads a clock, so two runs never agree, and the hashes are unique to the moment. Take the reproducibility here as a property of the teaching model. Everything else on this page survives the switch to a real clock. That one does not.

Build a block from the entry. Set its prev to the carried value. Hash it. Carry that hash forward. The third and fourth lines are ordinary; the second is the structure. Everything sessions 3 and 5 do is an attempt to survive that one assignment being wrong for a single block.

Notice also what the loop does not do. It does not check the entry, it does not ask who submitted it, and it does not compare it with anything. Those are sessions 7 and beyond, and none of them are supplied by the arrangement you are looking at.

Assembly takes a difficulty option, and the register uses 0, meaning each block's hash is computed once and accepted. Every structural property on this page holds exactly as it would at any difficulty: the fields, the link, the genesis convention, the reproducibility.

Raising the difficulty changes one thing only, which is how much a block costs to produce and therefore to redo. It is worth seeing the structure work with no cost attached at all, so that when session 4 attaches one you can say precisely what it bought.