How a Shared Ledger Is Checked and Secured

A shared ledger is useful only if participants can check it. In Bitcoin, a full node checks transactions and blocks against its rules rather than accepting a miner's claim at face value. This lesson explains blocks, hashes and validation in plain language. You do not need to write code to understand the separation between proposing a record and checking whether that record is acceptable.

Education only. Crypto assets can lose substantial value or become worthless. No lesson requires buying an asset, depositing money or sharing real passwords, private keys or recovery words.

Ask who keeps the record when nobody is in charge

Earlier in the course you saw Bitcoin's big promise: digital cash with rules for rejecting conflicting accepted spends, with no bank keeping the books. That raises a practical question. If nobody is in charge, who keeps the record, and why should anyone believe it?

Picture a tool library run by neighbours in Toronto. Each loan of a drill or ladder is written in one book, so the system depends on one keeper. Now imagine every member keeps a full copy of the loan book and adds each new line at the same time. If one person quietly changes their copy, the other copies disagree, and the change is noticed.

That is the heart of a blockchain: a record that many independent computers store and check, so no single keeper can rewrite it unseen. The analogy soon stops working, though. Neighbours trust one another's handwriting; Bitcoin nodes independently check applicable rules. They rely on mathematics that makes any change to the record stand out.

The tool that makes this possible is called hashing, and it is where the record's security starts.

Pack transactions into blocks

Bitcoin does not add payments to the record one at a time. It groups them into blocks, like pages in a ledger. Each block has two main parts: a list of transactions and a short summary at the top called the block header.

The header does not repeat every transaction. Instead it holds a single fingerprint that summarises all of them, called the merkle root. You can picture it as a hash of hashes: each transaction is hashed, those hashes are paired and hashed again, and so on, until one hash remains. If any transaction in the block changes, the merkle root changes too.

The header also contains the hash of the previous block's header. That one detail is what turns a pile of pages into a chain. You'll study what is inside an individual transaction in the transaction and fee lessons in Level 1. For now, focus on how the pages are tied together.

Link each block to the one before it

Think of a numbered receipt book where every new receipt must quote the fingerprint of the receipt before it. Receipt 3 quotes receipt 2's fingerprint, receipt 2 quotes receipt 1's, and so on back to the start. Bitcoin's chain works the same way, starting with the genesis block you met in the Bitcoin origins lesson in Level 1. The developer guide calls a block's distance from that first block its block height.

This chaining sounds simple, but it has a powerful consequence. It means you cannot quietly change one page without disturbing every page after it.

The order matters because an output that has already been spent cannot be used again in a later accepted spend. A block is not merely a screenshot of balances; it is part of a history whose rules must hold from one accepted state to the next.

Open diagram at original size ↗

Read diagram as text

The top row links three invented-height blocks. Each displays a previous hash, a Merkle root, its own hash and transactions.

In the lower row, editing transaction B in block 101 changes its Merkle root and hash. Crossed links show the recorded previous-hash references no longer matching. Later references must be rebuilt and all validity and accumulated-work requirements still met.

Make a fingerprint of any piece of data

Think about a fingerprint. It is tiny compared with a whole person, yet it identifies them. If you are given a fingerprint, you cannot rebuild the person from it, but you can check whether a particular person matches.

A hash does the same job for data. Feed any data into a hash function, from one word to an entire book, and it produces a short, fixed-length code. Bitcoin uses SHA-256, part of the Secure Hash Standard published by the US National Institute of Standards and Technology (NIST), which explains that such digests are used to detect whether a message has changed.

SHA-256 always produces 256 bits. Written in hexadecimal (the digits 0–9 and letters a–f), that becomes a string of 64 characters.

A fingerprint is only useful if it behaves predictably, so it helps to look at the rules a good hash follows.

Test the four rules of a good hash

A good cryptographic hash gives the same output for the same exact input. Small changes normally produce a very different fingerprint. It should also be impractical to reconstruct a suitable original input from its hash, or find two distinct inputs with the same hash.

The last point is an important qualification: possible inputs outnumber the fixed-size outputs, so collisions can exist mathematically. Security depends on finding a useful collision being computationally impractical under the function's assumptions. Say extremely unlikely to find, rather than claiming collisions are impossible.

Use a hash to spot a change

Suppose a project publishes a file and its expected hash through a trusted channel. After downloading the file, comparing its calculated hash with that value can help detect a damaged or different file.

That check is only as trustworthy as the reference. If an attacker replaces both a file and the hash shown on a fake website, the two can match perfectly. Obtain software through verified channels and use the publisher's documented signature-verification process where appropriate. A matching hash does not prove that a publisher is honest or that software is harmless.

The same distinction applies to a ledger: a hash makes data changes detectable, while validation rules and consensus determine which data the system accepts. Hashing a false statement does not turn it into a true one.

Changing the data will ordinarily produce a different result. It is not encryption: hashing does not provide a decryption key that recovers the original text. It is also not a user password or proof that the input was truthful.

A full node independently validates the relevant Bitcoin history and new blocks under its configured consensus rules. Checks include valid spending authorisation, no spending of an already spent output, acceptable transaction structure and permitted issuance. If a miner proposes an invalid block, compliant nodes reject it even if its producer expended computing effort.

Validation is different from looking up a balance on a website. An explorer presents information based on its own infrastructure. A full node checks the underlying records itself, although running one still requires appropriate software, storage and connectivity. You are not required to operate a node for this course. The important idea is that a miner proposes a block while a validating participant can check its rules. Large computing power does not grant permission to invent a spend from someone else's key.

Different jobs in checking a ledger

Ask who gets to write the next page

Earlier in the course your payment waited in the mempool until a miner picked it for a block. But thousands of computers hold the same record, so who decides which of them writes the next page?

Think of a savings group's shared notebook. If members voted on who writes next, one cheat could invent a hundred fake members and win every vote. Online, fake identities cost almost nothing, so "one person, one vote" cannot work.

The Bitcoin whitepaper made votes cost something real. It proposed "one-CPU-one-vote": the right to add a block goes to whoever proves they have done a large amount of computing work. It built on Adam Back's Hashcash, the anti-spam idea from the Bitcoin origins lesson in Level 1.

That work turns out to be a guessing game.

Play the guessing game nonce and target

Picture a lottery where anyone may print as many tickets as they like, but each ticket costs a little electricity. A ticket wins if its number is below a set limit. Nobody can predict a winning number, so the only strategy is to print tickets fast.

That is close to what miners do. A miner builds a candidate block and hashes its header with SHA-256. The developer guide says the block is valid only if that hash is below a threshold called the target. Because any change scrambles a hash completely (the shared ledger lesson in Level 1), the miner cannot steer towards a winner. They change one small field, hash again and check.

The lottery analogy breaks down in a useful place. A lottery needs an official to confirm the winner. Bitcoin does not.

Check the winner's work in a split second

Finding a valid hash takes the network an enormous number of guesses. Checking it takes one: any node hashes the header once and compares it with the target. Hard to produce, quick to verify: that is what makes proof of work useful.

Nodes check far more than the hash. A block with perfect proof of work but one invalid transaction, such as one spending an already-spent output, is rejected. So miners choose which transactions go in and in what order, while nodes decide what is valid. Miners usually prefer the highest fee rates, which is why your sat/vB choice in the transaction and fee lessons in Level 1 affected the wait.

How long is that wait on average, and what keeps it steady?

Keep blocks near 10 minutes with the difficulty dial

On average a new block arrives about every 10 minutes. No timer enforces this. It comes from how hard the guessing game is compared with how much guessing power is working on it, and because each guess is random, individual gaps vary widely.

To correct such drift, every node recalculates the target every 2,016 blocks. The developer guide says the network aims for 2,016 blocks to take two weeks: 2,016 × 10 minutes = 20,160 minutes, or exactly 14 days. Faster than that, and mining becomes harder; slower, and it becomes less hard.

If the Texas machines made 2,016 blocks take 12 days, difficulty would rise about 16.7%, pulling the pace back towards 10 minutes. If miners switch off, the dial turns the other way. All this guessing costs money, so why do miners keep going?

The network adjusts the difficulty under its rules so that block production responds to changes in total mining effort. Individual block times still vary; a target average is not an appointment for the next block.

Open diagram at original size ↗

Read diagram as text

The miner icons differ in machine count. Each dot represents another hash attempt with a new nonce.

A candidate below the target is highlighted and connected to checking nodes. The picture’s phrase valid block refers only to this proof-of-work test; the nodes must also check the other consensus rules.

The difficulty dial represents adjustment every 2,016 blocks. It does not select a miner or promise a winning time.

Two valid blocks can briefly appear near the same time, so different nodes may initially see different tips. Subsequent work can resolve that competition, leaving transactions in the discarded branch to be reconsidered. This is a reorganisation. Deeper accepted history is ordinarily harder to replace because a competing valid history must overcome more accumulated work, but the word irreversible is too absolute for every situation.

Security depends on assumptions about software correctness, network conditions and competing work. A rewrite attempt may reorder or exclude transactions and reverse the attacker's own recent payments under certain conditions. It does not magically reveal every private key or authorise arbitrary theft from every address. When discussing an attack, state exactly which rule or assumption is affected. The next lessons show how signatures authorise spending and how confirmations communicate a transaction's position in accepted history.

Everyday example

What to remember

Lesson completion check

References and further reading