03   Tampering

4 blocks · difficulty 3

See one change travel through the chain

Edit a block's data and see how its hash changes — and why later blocks can no longer prove one continuous history.

A guide by · Start a guided exercise · Read the articles

This is a simplified, local simulator — not a real blockchain network.
Invalid chain

Block 01

Valid
Index
01
Timestamp
Aug 26, 2026, 10:00
Data
Genesis block
Previous hash
0 (genesis)
Nonce
8,299
Hash
000d15874e8c9c7e…
All checks pass

Block 02

Invalid
Index
02
Timestamp
Aug 26, 2026, 10:01
Data
Previous hash
000d15874e8c9c7e…
Nonce
1,772
Hash
8cb1d134757e2164…
Hash misses target

Block 03

Invalid
Index
03
Timestamp
Aug 26, 2026, 10:02
Data
Order #1024 shipped
Previous hash
000e0e0873804d95…
Nonce
513
Hash
000c61367e34836d…
Previous hash mismatch

Block 04

Invalid
Index
04
Timestamp
Aug 26, 2026, 10:03
Data
Inventory update
Previous hash
000c61367e34836d…
Nonce
1,059
Hash
000d4de39c97a077…
Earlier history invalid

1. Edit block 02 data

23 / 512 characters

2. Hash comparison

000e0e0873804d95b512b7f381fda2b2e0b5ef21f85a7c63783cea954f5c99368cb1d134757e21646b969e4868f0e0b3f0aaf39291cda9bf21285b725181d829

Hashes do not match

3. Proof of work

000leading zeros

This updates block 02 and every descendant.

The chain is invalid. Check the reason under each block: block 02 may miss the target, block 03 may reference the old parent hash, and later blocks can extend invalid history even when their own checks pass. Re-mine from block 02 to repair the local suffix.

Guided practice

Predict. Change. Explain.

Four exercises use the same workbench above. Start each with Reset. All payment descriptions are fictional text; no funds move.

By · Technical content and exercises reviewed . Dates reflect content review, not simulated block timestamps.

01 · Hashing: change one character

What you will learn

Recognize a deterministic hash: identical bytes give the same digest, while a small edit usually changes many hexadecimal digits.

Try it step by step

  1. Press Reset in the workbench to restore the valid four-block chain.
  2. Read block 02: Payment of 25 to Alice. Compare Before edit and Current; they match.
  3. Change 25 to 250. Compare the full hashes, then restore the exact original text without re-mining.
Go to the workbench ↑

Expected result and why

The edit produces a different 64-character SHA-256 digest. Restoring the original text restores the original hash because the timestamp, nonce, index, and parent hash stayed fixed. The hash is computed from all of those fields, not the transaction text alone.

Common mistakes

A trailing space counts as data. Reset before comparing: re-mining can change the nonce. A hash is not encryption, and a different-looking digest does not tell you who changed the text.

What this simulation simplifies

This app hashes a pipe-delimited string once. Real protocols define exact byte encodings and data commitments. Hash collisions are possible in principle; they are not a practical way to repair this example.

Check your understanding: Why does restoring the text after re-mining not necessarily restore the Before edit hash?

Re-mining searches from nonce zero. If the nonce changed, the full hash input is different even when the text matches.

Read next: Why changing one transaction breaks a blockchain

02 · Chaining: validate the whole history

What you will learn

Separate a block’s own checks from the validity of the history it extends.

Try it step by step

  1. Press Reset. Match each block’s Previous hash to its parent’s Hash in the timeline.
  2. Edit block 02 to Payment of 250 to Alice. Read the reason below blocks 02, 03, and 04; scroll the timeline sideways on a phone.
  3. Use Add block, enter Classroom record, then Mine and add block. Predict whether a new mined block can repair the earlier history.
  4. Re-mine from block 02 and check every link again.
Go to the workbench ↑

Expected result and why

Block 03 keeps its old parent reference, so it no longer matches block 02. Block 04 can pass its own checks yet extend invalid history. Adding block 05 does not fix that. Re-mining in order updates each parent reference and restores the local chain.

Common mistakes

Do not treat a leading-zero hash as a complete validation result. A new valid tip does not cure a bad ancestor. Displayed hashes are shortened; the program compares all 64 characters.

What this simulation simplifies

These checks cover hash consistency, parent references, and a toy target. Real validation also checks transactions, authorization, spending rules, and protocol-defined genesis and block structure. No peers vote on this local result.

Check your understanding: If block 04’s hash stays unchanged after an edit to block 02, why does block 04 show Invalid?

Its own fields can be internally consistent while its ancestry is invalid. The UI labels cumulative history, not just the current block.

Read next: Why changing one transaction breaks a blockchainTransaction submitted versus transaction confirmedPreventing duplicate blockchain payments when requests retry

03 · Tampering: rewrite a payment record

What you will learn

Trace an attempted historical edit without confusing a local rewrite with a network accepting it.

Try it step by step

  1. Press Reset and note the payment in block 02.
  2. Change Payment of 25 to Alice to Payment of 250 to Alice.
  3. Check that block 02’s hash changes but block 03’s stored Previous hash does not.
  4. Re-mine from block 02. Compare the now-valid chain with the Before edit hash. Reset to discard the rewrite.
Go to the workbench ↑

Expected result and why

The new text breaks the original hash commitment. For this chosen edit, block 02 also misses the target. Repairing the local chain changes the descendants’ commitments; it does not make the new payment authorized or rewrite anyone else’s copy.

Common mistakes

Do not say all later stored hashes change immediately: they remain unchanged until re-mining. An arbitrary edit could happen to meet the target, but that would not fix the child’s old reference. The dollar sign in the initial demonstration is only text.

What this simulation simplifies

The browser deliberately lets you edit historical text. It has no signatures, balances, transaction execution, or competing honest chain. A real node would reject an unauthorized spend even inside a block with valid proof of work.

Check your understanding: Does a green chain prove Alice received a payment?

No. Green means the local teaching checks pass. The simulator never sends or executes payments.

Read next: Why changing one transaction breaks a blockchainTransaction submitted versus transaction confirmed

04 · Proof of work: search, then verify

What you will learn

Explain why finding a suitable nonce takes repeated attempts but checking a candidate requires one hash calculation here.

Try it step by step

  1. Reset, then change block 02 to Payment of 250 to Alice.
  2. Read the target: three leading hexadecimal zeros. Re-mine from block 02 and watch the current-block attempt counter.
  3. Inspect the resulting nonces and hashes. Each repaired block meets the target.
  4. Reset and repeat the same edit. Compare nonces. Then try different text and compare again.
Go to the workbench ↑

Expected result and why

The same starting fields and search order give the same nonces. Different input changes the search. With uniformly distributed digests, a three-zero target succeeds with probability 1/4096 per attempt, giving an expected 4096 attempts, not a deadline or guarantee. Attempts shown during mining restart for each block.

Common mistakes

A larger nonce is not a measure of a miner’s intelligence. One run cannot establish a timing benchmark. The simulator yields between batches, so wall-clock time includes browser scheduling.

What this simulation simplifies

Bitcoin compares a double-SHA-256 block-header hash against a numeric target and adjusts difficulty under its rules. This fixed target, single-hash demo has no hardware competition or rewards. Ethereum uses proof of stake, not this mining process.

Check your understanding: If a valid nonce is given to you, must you repeat all preceding failed attempts?

No. Recalculate the candidate hash and check the target. Real nodes must additionally validate the entire block and its transactions.

Read next: Why changing one transaction breaks a blockchain

Read the field notes

From a broken link to a reliable payment

Blockchain glossary

The concepts behind the experiment

28 reviewed terms, written for beginners and connected to primary technical sources.

Foundations

6 terms

Foundations

Blockchain

A sequence of records linked by cryptographic hashes and maintained under shared validation rules.

A blockchain groups data into ordered blocks and includes a reference to the previous block in each new block. That structure makes historical edits visible because changing one block changes its hash and breaks the reference held by the next block. Real blockchains also need a network and consensus rules; this field guide demonstrates only a small local chain.

Foundations

Block

An ordered container of data plus metadata used to verify and connect it to a chain.

A block typically contains or commits to transactions, a timestamp or slot, a reference to earlier history, and consensus-specific fields. This demo uses index, timestamp, data, previous hash, nonce, and current hash so the linking mechanism stays visible. Production block formats differ across protocols.

Foundations

Genesis block

The first block in a chain, created without a normal previous block reference.

The genesis block establishes the starting point from which later blocks derive their history. Its parameters are defined by the protocol or the local experiment. In this simulator its previous hash is represented by zero, while real networks define a specific genesis block and initial state.

Foundations

Hash

A fixed-length digest calculated from data so that even a tiny input change produces a very different result.

A cryptographic hash function maps an input message to a fixed-size digest. The digest is fast to recompute and helps detect whether the input changed, but it does not encrypt the original data and cannot by itself prove who created it. Blockchains use hashes inside block references, transaction identifiers, signatures, and proof-of-work schemes.

Foundations

SHA-256

A standardized cryptographic hash algorithm that produces a 256-bit message digest.

SHA-256 is one member of the Secure Hash Algorithm 2 family specified by NIST. This field guide uses it once over a simple serialized block for teaching. Bitcoin's actual block-header proof-of-work applies SHA-256 twice and compares the numeric result with a target, so the simulator is intentionally simplified.

Foundations

Previous hash

A block field that points to the cryptographic hash of the block immediately before it.

The previous-hash reference creates the visible chain. If an earlier block changes, its new hash no longer matches the value stored by its successor. Rebuilding a valid proof-of-work chain means updating that reference and redoing the required work for every affected descendant.

Proof of Work

6 terms

Proof of Work

Nonce

A value miners vary to produce different candidate hashes for the same block data.

In this simulator the nonce starts at zero and increments until the SHA-256 digest begins with the required number of zero characters. A real protocol defines exactly which header fields miners can change and evaluates a numeric target rather than a text prefix, but the repeated-trial principle is the same.

Proof of Work

Difficulty

A measure related to how hard it is to find a proof-of-work hash that satisfies the network target.

A stricter target leaves fewer acceptable hashes, so miners need more attempts on average. Networks such as Bitcoin adjust the target over time to regulate block production. This demo fixes difficulty at three leading hexadecimal zeros so mining finishes quickly enough for a browser lesson.

Proof of Work

Proof of work

A mechanism that makes producing an acceptable block computationally costly while keeping verification cheap.

A miner repeatedly hashes candidate block headers until one falls below the required target. Other nodes can verify the result with a small amount of work. In a chain, altering history requires repeating proof-of-work for the changed block and its descendants, then competing with the work of the accepted network chain.

Proof of Work

Mining

The process of constructing candidate blocks and searching for proof-of-work that satisfies the target.

Mining is more than guessing a nonce in a real cryptocurrency network: miners also select transactions, construct a candidate block, validate rules, and propagate a successful block. The field guide isolates the nonce-search step so learners can see attempts, the resulting hash, and the cost of repairing descendants.

Proof of Work

Chain validity

The result of checking every block's contents, proof, and link against the chain's rules.

This simulator calls a block valid when its stored hash matches its current fields, its hash meets the teaching difficulty, and its previous hash matches the actual predecessor. Real nodes enforce many additional consensus and transaction rules. A locally consistent chain is therefore not automatically accepted by any real network.

Proof of Work

Tamper evidence

The ability to detect that recorded data or its chain of references has changed.

Hash links make edits evident because the changed block gets a different digest and later blocks still point to the old value. Proof-of-work raises the cost of rebuilding that history, while a distributed consensus process decides which history participants accept. This is why “tamper-evident” is more accurate than saying data is literally impossible to change.

Networks & Consensus

10 terms

Networks & Consensus

Confirmations

How deeply a transaction’s block is buried in the currently selected chain.

In the usual Bitcoin convention, inclusion counts as one confirmation and each following active-chain block adds one. The count is meaningful only while the containing block remains in the selected history. A reorganization can reduce it or remove the inclusion. A confirmation threshold is an application risk policy, not a universal guarantee of settlement.

Networks & Consensus

Finality

A protocol-dependent assurance about whether accepted history can be replaced.

Finality is not a synonym for an HTTP success response or one block of inclusion. Bitcoin provides probabilistic settlement confidence through accumulated work. Ethereum proof of stake uses checkpoint finalization with supermajority stake votes and economic penalties under its safety assumptions. Finalization may stall; an application must observe the relevant network state rather than assume a timer guarantees it.

Networks & Consensus

Reorganization

A change to the selected chain that replaces a previously observed suffix.

When fork choice selects a different valid history, blocks previously treated as canonical can leave the active chain. A transaction in those blocks may be included elsewhere, return to pending, or conflict with the new history. Applications should retain inclusion block hashes and revisit unsettled observations. This local simulator demonstrates broken ancestry but does not implement competing branches or network reorganizations.

Networks & Consensus

Idempotency

Repeated attempts at the same logical operation preserve a single intended effect.

For a payment API, retries should reuse one durable operation identity bound to the same normalized parameters. Reusing that identity with a different payment must be rejected. Blockchain spending rules do not automatically deduplicate an order refund sent twice as two different valid transfers. Application idempotency requires durable storage, concurrency control, and reconciliation after ambiguous submission outcomes.

Networks & Consensus

Node

A computer running protocol software that exchanges, verifies, or stores blockchain data.

Nodes have different roles and capabilities. A validating node independently checks blocks and transactions against consensus rules, while lightweight clients may rely on compact proofs or other nodes for some data. The browser field guide has no peers, so it should not be mistaken for a node on a public network.

Networks & Consensus

Peer-to-peer network

A network in which participants exchange blocks and transactions directly rather than through one central server.

In Bitcoin's design, transactions and newly found blocks are broadcast among nodes. Peer-to-peer communication helps the network propagate a shared view without a single central publisher, but it does not eliminate protocol rules, unequal connectivity, operational concentration, or the need to handle conflicting messages.

Networks & Consensus

Consensus

The rules and process nodes use to agree on which state and history they will accept.

Consensus combines validation rules with a method for resolving competing histories. Proof-of-work is one ingredient in Bitcoin's consensus, not a synonym for every blockchain consensus system. This local simulator validates one chain in one browser and therefore does not demonstrate distributed agreement.

Networks & Consensus

Fork

A point where nodes temporarily or deliberately follow different valid-looking blockchain histories or rules.

A temporary chain fork can occur when miners produce competing blocks near the same time. Nodes keep track of alternatives and converge according to the protocol's chain-selection rule. The word also describes a lasting rule change that creates incompatible networks, so the surrounding context matters.

Networks & Consensus

Chain selection

The consensus rule nodes apply when more than one candidate blockchain history exists.

Bitcoin nodes select the valid chain with the most accumulated proof-of-work, often described informally as the longest chain. Raw block count alone is not the precise rule. Chain selection lets independently operating nodes converge after temporary forks when one history accumulates more accepted work.

Networks & Consensus

51% attack

A majority-hash-power attack in which one actor can outpace honest proof-of-work miners and reorganize recent history.

An attacker controlling most active hash power can build an alternative chain faster than the honest network, potentially reversing the attacker's own recent payments or censoring transactions. It does not reveal private keys or allow arbitrary signatures, and its feasibility and impact depend on the network and duration.

Ownership & Applications

6 terms

Ownership & Applications

Transaction

A protocol-formatted instruction, usually authorized by a digital signature, that proposes a state change.

A transaction can transfer value, call a smart contract, or perform another network-defined action. Nodes validate its authorization, format, and state-dependent conditions, including a signature when the protocol requires one. Broadcasting a transaction is not the same as having it included and confirmed in an accepted block.

Ownership & Applications

Wallet

An interface, application, or device that manages keys and helps a user interact with blockchain accounts.

A wallet does not normally store coins as files inside the device; the network records state while the wallet controls the credentials used to authorize actions. Wallet designs range from self-custody tools to services where another party holds keys, so users need to understand who can sign and recover access.

Ownership & Applications

Public key

The non-secret value in an asymmetric key pair, used to verify signatures or derive identifiers.

A public key can be distributed without revealing the private key. Depending on the protocol, addresses are derived from public keys rather than being identical to them. Others use the public key and signature to verify that a transaction was authorized by the corresponding private key.

Ownership & Applications

Private key

A secret value used to produce digital signatures that authorize actions for a blockchain account.

Control of a private key usually means control of the actions that key can authorize. It should not be shared or placed in a website form. Losing it can make self-custodied assets inaccessible, while exposing it lets someone else sign. Wallets often protect or derive keys from recovery material.

Ownership & Applications

Digital signature

A cryptographic value used to verify that the corresponding private key signed a specific message.

A signing algorithm combines a private key with a message digest to create a signature. Verifiers use the corresponding public key to check it. Signatures provide authorization and integrity evidence, but application rules still determine whether a signed transaction is valid, timely, and permitted.

Ownership & Applications

Smart contract

Program code deployed to a blockchain that executes according to the network's rules when called.

A smart contract stores code and often state at a blockchain address. Transactions invoke its functions, and every validating node reproduces the resulting state transition. The name does not guarantee that the program is legally a contract, intelligent, secure, upgradeable, or able to access off-chain facts without an additional mechanism.