Why changing one transaction breaks a blockchain

Start with a concrete edit

Reset the workbench, then change block 02 from Payment of 25 to Alice to Payment of 250 to Alice. The original chain records one statement; your edited copy records another. The immediate problem is not that text became unreadable. It is that the cryptographic references no longer describe one consistent history.

The workbench recalculates the edited block’s hash immediately. Block 03 still holds the old hash as its parent reference. Block 04 still points correctly to block 03, but the history beneath it is broken. This is why the interface distinguishes Previous hash mismatch from Earlier history invalid. Later stored hashes do not spontaneously change when you type.

A hash commits to bytes, not intentions

A hash summarizes an exact input. Changing a character, whitespace, or another hashed field normally changes the digest. Repeating the same input gives the same output. SHA-256 produces 256 bits, displayed here as 64 hexadecimal characters. Collisions must exist because there are more possible messages than digests; practical collision resistance, rather than mathematical uniqueness, is the useful property.

In this simulator, index, timestamp, data, previous hash, and nonce are joined with a pipe character and hashed once. The downloadable example below uses that same encoding. Restoring only the text after changing the nonce is not restoring the complete input. Nor does a matching digest establish who authorized a transaction: that is a separate question.

Primary sources: NIST · Secure Hash Standard

Bitcoin commits through a block header

Bitcoin does not concatenate payment sentences. Its serialized transactions feed a Merkle tree whose root is in the block header. The header also contains a previous-header hash. Altering transaction data changes the commitment and therefore the header hash, except for a cryptographic collision. Bitcoin hashes the header twice with SHA-256 for proof of work.

An edited header usually loses its acceptable proof of work. Even if it accidentally still meets the target, the next block’s old reference does not point to it. Rebuilding the affected suffix means updating those references and finding acceptable work again. Counting blocks alone misses a crucial Bitcoin rule: chain selection compares accumulated work among valid chains.

Primary sources: Bitcoin · Block headers and targetBitcoin · Block chain and validation

Repairing your copy is not winning consensus

Click Re-mine from block 02. The app rebuilds one local suffix in order and shows green when its checks pass. It deliberately gives you control over that copy. There is no race against honest miners, no propagation delay, and no other node deciding whether to accept your rewrite.

On Bitcoin, an attacker trying to replace accepted history must contend with work added by the network. The white paper analyzes that race under stated assumptions; it does not make rewriting mathematically impossible. More buried history generally makes an attack harder under those assumptions. A reorganization can still replace recent blocks.

Primary sources: Bitcoin white paper · Sections 4–6 and 11

Valid work cannot authorize an invalid payment

Changing an amount in an ordinary signed payment also changes data that authorization commits to. Validating nodes check spending and authorization rules, not just a hash target. An attacker cannot make an unauthorized spend acceptable merely by mining a good-looking header. The exact signature coverage and transaction rules depend on the protocol and transaction type.

The simulator omits those checks. Payment of 250 to Alice is a label, not an executed transfer. Its green state is evidence only of local hash, link, and target consistency. Use the chain-validation exercise to see why even a newly mined tip cannot repair an invalid ancestor.

Primary sources: Bitcoin · Block chain and validation

What the experiment establishes

The useful claim is tamper evidence: a modified record conflicts with existing commitments. Resistance to replacing that history comes from the surrounding validation and consensus system. Hashing, signatures, proof of work, and chain selection solve different parts of the problem.

Try the edit, restore the exact original text before mining, and watch the original digest return. Then repeat with re-mining in between. Explain the difference using the nonce. Next, read Transaction submitted versus transaction confirmed to connect local history to the uncertainty a payment application must track.

Runnable offline example

Save hash-change.mjs and run node hash-change.mjs with Node.js 20 or later. No dependencies, credentials, network access, or funds are needed.

// Offline classroom example. No network calls or payments.
import { createHash } from 'node:crypto';
import assert from 'node:assert/strict';
const block = {
  index: 1, timestamp: '2026-08-26T10:01:15.000Z',
  data: 'Payment of 25 to Alice',
  previousHash: '000d15874e8c9c7ef4d1fc3d005f4fd88b8f9d5ae86dd4e98a4753c0bcdf5c2a',
  nonce: 1772,
};
function hash(b) {
  return createHash('sha256').update(
    [b.index, b.timestamp, b.data, b.previousHash, b.nonce].join('|')
  ).digest('hex');
}
const original = hash(block);
const edited = hash({ ...block, data: 'Payment of 250 to Alice' });
assert.equal(original, '000e0e0873804d95b512b7f381fda2b2e0b5ef21f85a7c63783cea954f5c9936');
assert.notEqual(original, edited);
assert.equal(hash({ ...block }), original);
console.log('original:', original);
console.log('edited:  ', edited);
console.log('restored:', hash(block));

Practice and vocabulary

• 03 · Tampering: rewrite a payment record
• 01 · Hashing: change one character
• 02 · Chaining: validate the whole history
• 04 · Proof of work: search, then verify