How Blockchain Works | Proof of Work and Targets

A fictional club chooses a game for selecting a notebook proposal. A candidate produces a number through a defined procedure. The number must fall below an agreed threshold to pass the game.

This introduces a target: a condition that distinguishes acceptable results from unacceptable ones.

Real proof-of-work systems use cryptographic computations, not our classroom number cards. Bitcoin checks a block header hash against its protocol-defined target.

The important beginner idea is repeated search. A participant tries candidates until it finds a result meeting the rule.

This is not usually a contest to solve a meaningful school equation or discover a new scientific theorem.

Our paper game will illustrate probability and checking only. It is not a mining implementation, a description of current hardware or advice to spend money participating in a cryptocurrency network.

Contents · Next chapter

The digital-fingerprints guide explained that a cryptographic hash is calculated from bytes according to a defined function.

For Bitcoin’s proof of work, the relevant computation concerns the block header in its specified format. Changing relevant candidate data changes what is hashed.

The search does not ask a participant to look at a paragraph and choose an attractive fingerprint. The procedure is deterministic for a fixed input.

Our fictional number game stands in for the distribution of candidate results, not for the actual hash calculation.

Keep the distinction visible. We can understand why a target makes a result rare without pretending that writing random numbers on paper performs cryptographic work.

The real check requires the right bytes, algorithm and target. A simplified analogy is useful only when the reader knows which mechanics it leaves out.

Contents · Previous chapter · Next chapter

A candidate result fails to meet the fictional threshold. The participant tries another candidate.

The failed attempt does not mean the next result must be closer to success. Under the simplified independent-trial model, each new attempt has the same chance for a fixed target.

This differs from a school exercise where each completed algebra step moves toward a known solution.

The proof-of-work search is often described through repeated hashing and candidate changes. More attempts per second can change the expected rate of finding qualifying results; it does not make each individual attempt a guaranteed step toward one.

Our paper model uses replacement when drawing number cards so earlier failures do not remove future possibilities.

This chapter supplies a probability intuition. It should not be read as a complete mathematical model of every mining process or every change in real network conditions.

Contents · Previous chapter · Next chapter

Imagine the fictional game produces equally likely whole numbers from zero through ninety-nine. A qualifying result must be less than ten.

Ten possible results pass: zero through nine. The chance per independent draw is ten in a hundred.

Now lower the target so the result must be less than five. Only five possible results pass. The game has become harder under this model.

Real proof-of-work targets operate over much larger numerical ranges and follow protocol rules.

The direction is the useful idea: a smaller allowed range makes qualifying results rarer.

Do not confuse difficulty with a bigger permitted number merely because the ordinary word harder sounds larger. The numerical target and a displayed difficulty measure can move in opposite directions. Their relationship needs to be explained instead of guessed from their names.

Contents · Previous chapter · Next chapter

The fictional participant reports a result of three for a target of five. A checker can compare three with five immediately.

In a real proof-of-work system, another node recomputes the required hash and checks it against the correct target. Finding a qualifying candidate can require many attempts, while checking one candidate is comparatively straightforward.

That asymmetry is central to the idea.

The checker does not need to trust a participant’s claim that it worked for a particular number of hours. It checks the qualifying result under the rules.

Our paper example omits the hash computation, so it only illustrates the final comparison. A real verifier must establish that the reported result actually comes from the specified candidate data.

A small number written on a card is not proof unless the checking procedure connects it to the relevant input.

Contents · Previous chapter · Next chapter

Proof-of-work explanations often introduce a nonce: a value varied while searching through candidate headers.

It is part of the candidate data, not a transferable permission to change arbitrary ledger history.

Real miners can construct different candidates in several protocol-permitted ways when searching. A simplified story in which only one small field changes does not describe every implementation detail.

Our fictional game labels each attempt with a candidate number. The label helps track the search but does not implement Bitcoin’s header structure.

This chapter also prevents a vocabulary collision. The transaction nonce in an account-based system serves a different role from a proof-of-work header nonce.

The same word can appear in different mechanisms. Ask what object contains the value and which rule uses it before assuming that two uses of nonce mean the same thing.

Contents · Previous chapter · Next chapter

A fictional notebook proposal passes the target game but includes an unauthorised equipment entry. The club’s separate validity rule still rejects it.

Proof of work does not automatically make every transaction in a block valid. Full validating nodes apply the relevant block and transaction rules as well as the work condition.

This distinction is essential. Computational effort is one part of the consensus design, not a permission to break every other rule.

A reader should therefore separate the target check from the content checks.

Our paper model gives the proposal two boxes: game condition and record validity. Both must meet the exercise’s requirements.

A claim that a miner can create any accepted balance merely by finding a low hash confuses those boxes. A valid chain-selection process operates among histories that satisfy the applicable protocol rules.

Contents · Previous chapter · Next chapter

The fictional club publishes the target according to its game rules. A participant cannot make the game easier for its own proposal by declaring a larger permitted range.

Bitcoin nodes check that a block uses the target required by the protocol at that point.

The work condition is therefore not simply whatever threshold the candidate producer writes down.

This connects proof of work to the governance and rule-change guides. The producer chooses candidate data within constraints; it does not independently rewrite the network’s acceptance policy.

Our paper exercise includes an attempted self-chosen target and rejects it before comparing the result.

The beginner lesson is that a proof is always relative to a rule. Finding a qualifying result under the wrong rule does not establish the required claim, even if the calculation itself is correct.

Contents · Previous chapter · Next chapter

If the fictional game receives many more attempts per minute, qualifying results will be found more frequently on average under a fixed target.

A protocol can adjust its target according to defined rules to influence the expected block-production rate.

Bitcoin uses a specified retargeting process. This guide does not reproduce every timing rule or numerical limit.

The important word is expected. Adjustment does not schedule each future block at an exact clock appointment.

A probability-based search still produces variation. One qualifying result can arrive quickly and another after a long wait.

Our classroom graph can show uneven gaps around an average. It should not draw a perfectly regular metronome and label that proof of work.

The mechanism relates a target to observed or modelled work conditions; it does not guarantee that every individual waiting time equals the network’s nominal interval.

Contents · Previous chapter · Next chapter

A participant reports one qualifying fictional candidate. The checker sees that result, not a complete list of all failed attempts made before it.

A qualifying proof does not directly reveal the exact physical effort that produced it. Someone can be lucky on one attempt or unlucky across many.

Protocol work measures are derived from the target and rules rather than a stopwatch attached to each miner.

This is why accumulated work should not be explained as the exact number of electricity units visibly recorded inside a chain.

Our paper model separates attempts we happen to observe in class from the evidence contained in the winning card.

The distinction is subtle but useful: a rare qualifying result supports a rule-defined work measure under the model. It is not a receipt itemising the producer’s actual failed calculations.

Contents · Previous chapter · Next chapter

The forks guide introduced competing valid branches. Bitcoin’s chain-selection rule compares accumulated work in the relevant valid chains.

A simple block count is an incomplete explanation when targets and per-block work can differ.

Our fictional club can assign a defined work score based on each accepted target, then compare branch totals. Those scores illustrate a rule, not measured sweat or hours.

Selection and validity remain separate. A branch with invalid contents does not become valid because someone claims a larger total.

This chapter explains the role of work in a shared-history decision. It does not claim that every blockchain uses Bitcoin’s method.

Ask which chain-selection evidence the network actually counts. The right answer is protocol-specific, and the phrase longest chain often hides the important qualification that the work measure, not merely the visual length of a line, matters.

Contents · Previous chapter · Next chapter

A fictional entry has been included on a selected branch. Later qualifying blocks add work after it.

Under a proof-of-work security model, replacing the relevant history faces a different work competition as that context changes.

This is part of why confirmation depth can matter. It is not an absolute promise that a fixed number of later blocks makes every reversal impossible.

The confirmations-and-finality guide explains why settlement claims need their network and assumptions.

Our paper example does not prescribe a waiting policy for real payments. It shows that early inclusion and later accumulated evidence are different stages.

A careful explanation names the accepted branch and relevant work context. It avoids promising universal certainty from a borrowed count, while also recognising that the protocol’s work mechanism contributes meaningful evidence under its stated model.

Contents · Previous chapter · Next chapter

A fictional participant can try more candidates each second than another. That changes its opportunities in the search.

It does not let the participant instruct a correctly validating node to accept an unauthorised record.

Real proof-of-work participation involves hardware, energy, infrastructure and organisational arrangements. These affect who can perform work and how production is distributed.

Our guide does not recommend equipment or compare profitability.

The conceptual question is which capability the resource buys: more candidate attempts, rather than a universal exemption from validity rules.

This distinction also keeps a decentralisation claim honest. The mechanism can be permissionless in a particular sense while the actual production resources are unevenly distributed. Whether influence is concentrated requires evidence about the relevant system, not merely the fact that a hash function is publicly specified.

Contents · Previous chapter · Next chapter

Repeated computational search consumes real resources. The fictional number game hides that physical cost because paper cards are easy to shuffle.

A serious explanation of proof of work should acknowledge the resources used to produce attempts. Quantifying the current footprint of a network, however, requires evidence and a stated measurement method.

This guide supplies no current energy estimate and makes no claim that every proof-of-work implementation has the same footprint.

The comparison to proof of stake concerns different security mechanisms, not a simple claim that one performs no work of any kind.

Software, communication and operation still require resources in every real system.

For beginners, keep the mechanism and measurement separate. We can explain why repeated hashing has a resource cost without inventing a number or pretending that a toy probability example measures the real network’s physical impact.

Contents · Previous chapter · Next chapter

The fictional notebook contains a report that a ball was delivered. Its candidate passes the target rule and its transactions satisfy the program’s validity conditions.

That still does not make the computation an independent observation of the physical delivery.

The oracle and supply-chain guides establish the outside-data boundary. Consensus helps participants agree on accepted records; it does not automatically guarantee that every submitted real-world statement is accurate.

This is a recurring distinction because it is easy to lose when a security mechanism sounds impressive.

Our paper model can mark the entry as accepted while leaving delivery evidence in a separate box.

The useful sentence is narrow: the block meets specified protocol conditions in the relevant history. A broader factual claim needs a supported connection from the outside event to the recorded data.

Contents · Previous chapter · Next chapter

Some blockchain systems use proof of work; others use proof-of-stake or other consensus designs.

Their proposal, voting, selection and settlement rules can differ substantially. The word blockchain does not select one universal mechanism.

Ethereum’s current proof-of-stake documentation and Bitcoin’s proof-of-work documentation describe different examples. A beginner should not combine their terms into an imaginary protocol that neither uses.

This guide has focused on Bitcoin-style targets and work comparison, with explicit simplifications.

The next guide examines validator duties in proof of stake. It will ask what is checked, who signs and what protocol consequences apply, rather than searching for a qualifying header hash.

The comparison becomes useful once each mechanism is understood on its own terms. Start with the actual rule, then compare the responsibilities and assumptions it creates.

Contents · Previous chapter · Next chapter

Write the numbers zero through ninety-nine on fictional cards and draw with replacement. Declare that a result below ten qualifies.

Count successful draws over a small trial, while remembering that your observed percentage need not equal ten percent exactly.

Now use a target of five and explain why the expected qualifying chance is smaller. Do not describe earlier failures as guaranteeing success on the next draw.

Add a second rule requiring an authorised notebook entry. A qualifying number attached to an unauthorised entry must still fail the complete exercise.

Finally give two fictional branches protocol-defined work scores and compare totals instead of counting pages.

No hashing, mining hardware or cryptocurrency is involved. The exercise is a probability and validity model that makes the target, candidate and checking conditions easier to separate.

Contents · Previous chapter · Next chapter

Proof of work uses a search for a candidate satisfying a specified computational condition. The target determines how restrictive that condition is, while the verifier checks the candidate under the applicable rule.

Bitcoin also validates block contents and compares work across valid histories. Passing the target is not permission to ignore those other checks.

Carry three questions into the technical companion: what data is hashed, which target is required and how is accepted work used in chain selection?

Our tiny game explains rarity and expected effort without pretending to measure real energy use or produce mining advice.

The strongest beginner understanding is a connected one: candidate search, efficient checking, protocol validity and accumulated evidence each have a distinct role. Keeping those roles separate prevents the phrase difficult puzzle from doing more explanatory work than it can support.

Contents · Previous chapter · Worked situations