Skip to content
Satnam SatoshiIn service of humanityFind your place ↗
Menu

Sikh Bitcoin · Advanced · Lesson 6 of 21

Block headers and the chain of work

Trace how compact headers bind a transaction history.

About 14 minutes with practice. You only need something to take notes with. No real wallet details or payments are part of this lesson.

Course contents · Lesson 6 of 21
  1. Read the whitepaper as an argument
  2. Hashes and Merkle commitments
  3. UTXOs, change and accounting
  4. Scripts describe spending conditions
  5. Signatures and what they authorize
  6. Block headers and the chain of work
  7. Difficulty, hashrate and noisy observations
  8. Issuance, fees and incentives
  9. Mempools and policy are not consensus
  10. Fee changes: RBF and CPFP
  11. SegWit and transaction weight
  12. Taproot and Schnorr: useful, not magical
  13. HD wallets and derivation paths
  14. PSBT: separate construction from signing
  15. Descriptors make a wallet policy portable
  16. Full nodes, pruning and verification
  17. Reorganizations and lightweight evidence
  18. Lightning channels and HTLCs
  19. Lightning liquidity has direction
  20. Soft forks, proposals and human coordination
  21. Capstone: trace a payment end to end

What you will learn

  • Identify the role of previous-block and Merkle commitments.
  • Distinguish header checks from full block validation.

Two commitments join the structure

A block header links to the previous block and commits to its transactions through a Merkle root. It also contains fields used in proof-of-work validation. Linking headers allows a verifier to evaluate accumulated work and ordering. The transaction data remains necessary for a full node to validate the actual spends and other rules.

Compact evidence has a boundary

Headers are smaller than full blocks, which makes them useful for lightweight verification. But a chain of plausible headers cannot by itself prove that every transaction inside the corresponding blocks is valid. A lightweight client relies on additional assumptions and evidence. Describe the assurance level honestly instead of calling every explorer lookup equivalent to running a fully validating node.

Use a chain sketch

Draw three fictional blocks as boxes. Put a previous-header link and a transaction-root label in each. If a transaction in the first box changes, its root changes and the links above it no longer match the original history. The exercise explains commitments; it does not calculate the real cost of an attack. That cost depends on work, network behavior and the adversary, not the artistic length of a drawing.

Practice on paper

A service verifies headers and an inclusion path but does not execute the block’s transaction rules. What can it claim more narrowly than “fully verified Bitcoin”?

Reveal the worked answer

It can describe header-chain and transaction-inclusion checks under its assumptions. It should disclose that it did not independently validate every transaction and spending condition in the full chain.

Check your understanding

Choose an answer in your head or on paper, then reveal the explanation. Retry whenever you like. Answers are not submitted or scored; completion marks are your own learning notes.

1. Does a header include every transaction’s full contents?

  • Yes
  • No
Reveal answer 1

No. It commits to them through a root.

2. Is header verification identical to full validation?

  • Yes
  • No
Reveal answer 2

No. The data and checks differ.

Take this with you

State exactly which evidence your verifier checked.

Your learning, at your pace

Read every lesson freely. Optional progress tracking needs JavaScript and browser storage; it does not require an account or wallet.