中文版 · Blockchain learning guide · Previous article
Blockchain learning · Article BC025
Proof of work lets a verifier check that a candidate satisfies a specified computational condition without trusting the producer’s claim about how long it worked. In Bitcoin, a block header’s hash must meet a target required by the rules. A node still checks the other validity conditions, then compares eligible histories using accumulated work rather than simply counting visible machines or blocks.
This guide separates three tasks: checking a hash against a target, assigning the work measure associated with that target, and comparing valid branches. We will use reproducible SHA-256 examples and a deliberately tiny numerical model. The model is not Bitcoin’s header format or a practical mining system, and the lesson contains no equipment, profitability or investment guidance.
Choose your reading route
In this guide
- 1. A target is an acceptance boundary
- 2. Fix the exact candidate bytes
- 3. Reproduce three sample trials
- 4. Expected trials are not a receipt for actual trials
- 5. An unusually low hash does not create bonus work
- 6. Calculate work in an eight-bit classroom model
- 7. Compare two valid branches with different lengths
- 8. Validation comes before the ranking
- 9. Changing the candidate means checking again
- 10. Six worked questions
- 11. A verifier’s reading checklist
- 12. Frequently asked questions
- Sources and next learning steps
Start with the target and exact-input example to understand what a verifier checks. If you already know hashes, move to the distinction between expected work and actual attempts, then calculate the two competing branches. The failure cases and final worksheet test whether you can keep validation separate from ranking.
A hash fingerprint by itself does not prove that searching for it was difficult. The difficulty comes from the additional acceptance condition and the assumptions about finding an input that satisfies it. Keep those two ideas separate throughout the lesson.
Back to contents · Next section
1. A target is an acceptance boundary
Imagine a hash-like output represented by one byte, so its numerical value lies between 0 and 255. Set a toy target of 15. An output passes if its value is less than or equal to 15: the successful values are 0 through 15, including both endpoints.
There are therefore 16 successful values out of 256 possible byte values. Under a uniform-output model, one independent attempt succeeds with probability 16/256, or 1/16. A lower target allows fewer successful values and makes success less likely per attempt.
The comparison is numerical. It is not a vote about whether the hash looks impressive, and it is not a measure of how many zeros someone typed into a report. Leading zero patterns can help people visualize a small number in a fixed representation, but the actual comparison is against the target.
Bitcoin uses a much larger numerical space. Its block-header reference describes a target encoded in the header and a header hash that must be at or below it. The byte-sized model here is only a teaching reduction; its values are not Bitcoin difficulty settings.
Back to contents · Next section
2. Fix the exact candidate bytes
For our reproducible exercise, the candidate is the UTF-8 encoding of the following pattern: archive-demo|parent=Q|records=R|nonce=N. Replace N with an ordinary decimal integer, with no leading zeros, spaces, quotation marks or final newline.
The strings Q and R are literal classroom labels. They are not real block hashes or a real transaction commitment. The word nonce names the changing field in this example; it has no value outside the supplied string format.
Apply SHA-256 once to the entire candidate. Read the first two hexadecimal characters of the digest as one unsigned byte. That byte, not the whole digest, is what our toy rule compares with 15.
These choices are explicit because an invisible newline, a changed character or a different encoding changes the input. “I hashed the same text” is not enough if one tool silently appended a line break. Reproducibility begins with bytes, not with a visual resemblance between two screens.
The exercise also deliberately differs from Bitcoin: real Bitcoin block headers use a specified binary layout, and the proof-of-work hash uses double SHA-256 over that header. Do not submit our text strings as if they were protocol objects. Their purpose is to make a small verification calculation inspectable.
Back to contents · Next section
3. Reproduce three sample trials
With nonce 0, the exact input is archive-demo|parent=Q|records=R|nonce=0. Its SHA-256 digest is f24ce500e8c7141106d109c24cc6928616508b65641b0ba0112fd71b35592937. The first byte is hexadecimal f2, decimal 242, so it fails the target of 15.
With nonce 2, the digest is 1e9d36698df1e4fe4970e28069c1aae26a76bdf086effd006affb9599a5ee1e0. Its first byte is hexadecimal 1e, decimal 30, so this candidate also fails.
With nonce 13, the digest is 0cea7f12b0e6489aafb77d47fb3226d855ed034d2a0933f6d31c1ceb35dc3727. Its first byte is hexadecimal 0c, decimal 12, so it passes.
Checking nonces 0 through 13 in increasing order gives the byte values 242, 80, 30, 129, 106, 209, 114, 126, 195, 221, 41, 169, 182 and 12. The first 13 candidates fail; the fourteenth candidate passes. We count 14 trials because nonce 0 is also a trial.
A verifier given the successful candidate need not repeat the 13 failed trials. It can hash that candidate and check the condition. This asymmetry between searching and checking is the central teaching point, while the deliberately easy first-byte condition makes our example simple to check.
Back to contents · Next section
4. Expected trials are not a receipt for actual trials
Under the exercise’s independent uniform-output model, a success probability of 1/16 gives an expected waiting time of 16 trials. The actual deterministic sequence above succeeded on trial 14. There is no contradiction: an expectation is not a promise about each sequence.
Someone might succeed on the first candidate or need far more than 16. Finding a passing result does not reveal an authenticated counter of the producer’s failed attempts, machine time or electricity use. Our list of 14 trials is known because the exercise explicitly computed and recorded that search order.
Nor does the nonce value itself prove the number of attempts. A producer could start at a different number, search in parallel or change another allowed field. A nonce of 13 is an input value, not a trustworthy receipt showing exactly 14 units of effort.
This distinction explains why a protocol associates work with the target condition rather than accepting a producer’s claimed hours. The system needs a reproducible measure that verifiers can derive from the rules and candidate, not a private activity log that the producer can embellish.
Even the phrase “computational work” needs care. The successful object evidences satisfaction of a search condition under the hash assumptions. It does not prove who owned the hardware, whether the controller was independent, or the truth of any physical-world statement carried by a transaction.
Back to contents · Next section
5. An unusually low hash does not create bonus work
Our passing first byte is 12 under target 15. Suppose another candidate has first byte 1 under that same target. Both satisfy the condition. In the work-accounting model used here, the second does not receive extra credit merely because it was luckier.
The assigned work comes from the required target, not the accidental distance below it of a successful output. Otherwise, the accounting rule would be different and would need its own definition and analysis. Do not infer such a bonus from a visually striking hash.
For a concrete implementation reference, Bitcoin Core’s chain-work calculation derives the work contribution from the encoded target. The linked development branch can change; the source was checked on the date listed below. Our small formula in the next section is an analogy for arithmetic practice, not copied production code.
This also prevents a reporting mistake: “this block has more leading zeros” does not by itself establish that its branch has more cumulative work. You need the required targets and the contributions along the eligible history.
Back to contents · Next section
6. Calculate work in an eight-bit classroom model
Define the toy work contribution for a valid block as the integer part of 256 divided by target plus one: floor(256/(target+1)). The parentheses matter. The denominator includes the extra one because zero is a successful output when the comparison is inclusive.
With target 63, there are 64 passing values, so the modeled success probability is 64/256 and the assigned contribution is 4. With target 31, there are 32 passing values and the contribution is 8. With target 15, there are 16 passing values and the contribution is 16.
For these selected targets, the division is exact. With another target, an integer work measure and the reciprocal success probability need not be numerically identical because of rounding. The lesson deliberately chooses simple values so the branch comparison can be checked without hiding that distinction.
These values are dimensionless teaching units. They are not seconds, joules, currency or observed hashes actually computed by a particular producer. Multiplying them by an invented price would not turn the exercise into a profitability estimate.
The model supplies each block’s required target as valid under its fictional rules. A producer is not allowed to choose a convenient target and demand acceptance. Real protocols specify how the required target follows from context; our exercise does not reproduce Bitcoin’s adjustment schedule.
Back to contents · Next section
7. Compare two valid branches with different lengths
Both branches start at the same supplied ancestor Q. We can omit their shared earlier contribution because it is identical on both sides. The classroom problem supplies all descendant blocks as fully validated, including their required targets.
Branch A has three blocks after Q. Each has target 63 and contributes 4 work units. Its added cumulative work is 4+4+4=12.
Branch B has two blocks after Q. Each has target 31 and contributes 8 work units. Its added cumulative work is 8+8=16. Under our rule of choosing the eligible branch with greater cumulative work, B wins despite having fewer blocks.
This is a numerical illustration of why block count and accumulated work are different quantities. It is not a claim that these exact target schedules would be valid for two short Bitcoin forks from the same ancestor. Their permissibility is supplied by the fictional model.
If A gained another valid target-63 block, its total would become 16, tying B. Our worksheet does not specify a tie-breaking rule, so that modified case cannot be uniquely decided from the given information. If A gained two such blocks instead, its added total would be 20 and exceed B’s 16.
A branch preference remains separate from an absolute guarantee about all future history. The exercise is a comparison over a fixed candidate set, not a universal finality proof or a recommendation about how many confirmations a real transaction requires.
Back to contents · Next section
8. Validation comes before the ranking
Now add branch C. It advertises 100 work units, but one of its blocks contains a state transition forbidden by the exercise’s validation rules. Under the supplied rule, C is ineligible. It does not beat A or B merely by claiming a larger number.
There are several independent questions a verifier must keep separate: did the candidate meet the correct target, was that target required in its context, did its data match the required commitments, and were the block and state transitions otherwise valid? Passing one check does not waive the others.
Bitcoin Core’s proof-of-work checks show target and hash validation in a real implementation. Those functions are part of a larger validation system, not a standalone proof that every transaction or history is valid. The Bitcoin developer guide also qualifies branch comparison in terms of valid blocks.
For the classroom worksheet, write “invalid; excluded” beside C instead of assigning it a place in the valid ranking. That wording makes it harder to mistake an impressive advertisement for an accepted fact.
Back to contents · Next section
9. Changing the candidate means checking again
Suppose the producer changes records=R to records=S after finding nonce 13. The old digest does not authenticate the changed input. The verifier must hash the new exact bytes and evaluate the new result. The old successful trial is not transferable just because the nonce is unchanged.
In a real block structure, commitments and parent references connect the header to particular contents and ancestry. A change may propagate through those commitments and require a different header calculation. This lesson does not claim that any text field can be substituted directly into a Bitcoin header.
The useful principle is narrower: the checked work condition belongs to a particular candidate under a particular rule. It is not a general certificate that the producer may attach to any document, transaction or branch it later prefers.
Likewise, a correct hash under the wrong target is not enough. If the contextual rule requires target 15, a candidate with first byte 30 cannot pass by announcing target 63. The easier target changes the question rather than answering the original one.
Back to contents · Next section
10. Six worked questions
- Does byte value 15 pass target 15? Yes. The comparison is inclusive. Value 16 fails.
- Does nonce 13 prove the producer made exactly 14 attempts? No. Our recorded sequential exercise did, but the nonce alone is not an attempt counter.
- Under target 15, does successful byte 1 earn more modeled work than successful byte 12? No. Both receive the same target-derived contribution under our rule.
- Which branch wins: three target-63 blocks or two target-31 blocks? The latter contributes 16 rather than 12, assuming all required targets and blocks are valid.
- An invalid branch advertises 100 units. Where does it rank? It is excluded before valid-branch comparison.
- The target required by context is 15, but the candidate advertises 63 and has byte 30. Is it acceptable? No. It fails the required target and cannot authorize its own easier condition.
For an extension, ask whether 16 expected trials means that 16 attempts guarantee success. It does not. Under the independent model, the probability of no success in 16 trials is (15/16) raised to the sixteenth power, which is greater than zero. A mean waiting time is not a deadline.
Back to contents · Next section
11. A verifier’s reading checklist
Before accepting a work claim in a document, identify the exact candidate format, hash procedure, numerical interpretation and target comparison. Then identify where the required target comes from. A target chosen only by the claimant cannot support the intended difficulty rule.
Before comparing histories, confirm which branches are eligible and how each work contribution is derived. Record cumulative work separately from height. If the comparison has a tie, do not invent a tie rule that the specification did not provide.
Finally, state the conclusion at the right level. “This candidate satisfies the toy target” is narrower than “this block is valid,” which is narrower than “this branch is selected.” None automatically means that a real-world claim is true or that future history cannot change.
Back to contents · Next section
12. Frequently asked questions
Is proof of work the same as a hash?
No. Hashing is an operation. Proof of work adds a specified acceptance condition whose satisfaction is intended to require search under the relevant assumptions.
Is the longest chain always the chain with the most blocks?
That phrase can be misleading. In the Bitcoin context discussed here, valid cumulative work matters. Our two-branch example deliberately gives the shorter branch the larger work total.
Can a lucky hash prove a particular electricity bill?
No. A passing result and target do not authenticate the producer’s actual hardware, number of attempts or energy consumption.
Does more work make an invalid transaction valid?
No. The validation rules remain binding. Work-based ranking applies to eligible histories, not to anything that advertises a large work total.
Back to contents · Next section
Sources and next learning steps
Primary references checked on 12 October 2026, Singapore time: the Bitcoin block-header reference, Bitcoin developer guide, Bitcoin Core chain-work source and proof-of-work source. Only the stated header, target, validation and work-accounting concepts are used; unrelated historical parameters in the documentation are not treated as current guidance.
The exact SHA-256 trial strings and eight-bit branch arithmetic are original classroom examples, independently reproducible without connecting to a blockchain. Next, compare proof-of-stake participation: what proposals and attestations do, which actions the protocol checks, and why being offline is a different condition from signing incompatible messages.