Detect sensor-record tampering with hashes

Steps

Screens captured against JupyterLite Python 3.12.7 / Pyodide 0.27.6; Chromium 148.0.7778.96 on 2026-09-10; the tool may have moved on — the text steps are the contract.

1. 1 Step 1

   Do

   Run `python3 main.py --step 1` to canonicalise one sensor record before hashing it.

   You will see

   The terminal prints the cold-001 fields, their compact sorted JSON, its full SHA-256 digest, and the rule that identical field ordering and values must reproduce it.

   Why it matters

   A verifier needs a stable byte representation; hashing an ambiguous serialization makes later comparison unreliable.

2. 2 Step 2

   Do

   Run `python3 main.py --step 2` to append four fictional readings to a hash chain.

   You will see

   A four-row table shows every event and temperature beside its previous-hash and block-hash prefixes; the genesis and link rules follow the table.

   Why it matters

   Showing both hashes makes the chain relationship inspectable instead of presenting only a final head digest.

3. 3 Step 3

   Do

   Run `python3 main.py --step 3` to verify the untouched chain.

   You will see

   Blocks 0 through 3 each show MATCH for content_hash and previous_link, followed by `Verifier: all content hashes and previous-hash links match.`

   Why it matters

   A known-good run proves the verifier checks both content and linkage before the deliberate failures are introduced.

4. 4 Step 4

   Do

   Run `python3 main.py --step 4` to alter cold-003 from 5.4 C to 2.4 C without changing the stored hash.

   You will see

   The stored and recomputed 64-character hashes differ beside the hash rule, and verification reports `FAIL at block 2: stored hash does not match record content.`

   Why it matters

   The failed block and violated rule identify the first inconsistent record rather than merely reporting that the ledger is invalid.

5. 5 Step 5

   Do

   Run `python3 main.py --step 5` to recompute only the altered block's hash and verify again.

   You will see

   Block 2 gets a new hash while block 3 retains the old previous_hash; verification reports `FAIL at block 3: previous_hash does not equal prior block hash.`

   Why it matters

   This demonstrates why hiding a historical edit requires rewriting every later link, not just the changed block.

6. 6 Step 6

   Do

   Run `python3 main.py --step 6` to hash the same four records into a two-level Merkle tree.

   You will see

   The terminal prints four leaf prefixes, two parent prefixes, the full Merkle root, and `parent = SHA-256(left child hash + right child hash)`.

   Why it matters

   The intermediate hashes show how one compact root commits to the whole off-ledger batch.

7. 7 Step 7

   Do

   Run `python3 main.py --step 7` to replay the Merkle root after changing cold-003.

   You will see

   The anchored and replayed roots differ beside `Rule: replayed root must equal the anchored root`, followed by `Verification FAIL` and the consistency-versus-truth scope warning.

   Why it matters

   A root mismatch detects changed evidence, while the scope line prevents treating hash consistency as proof that the physical probe was truthful.