Skip to content
Satnam SatoshiIn service of humanityFind your place ↗
Menu
Lesson 17 / 21 · Advanced

Reorganizations and lightweight evidence

Understand why history observations have different strengths.

14 MIN WITH PRACTICEREAD → TRY → REFLECTNO WALLET NEEDED

By the end, you’ll be able to…

  • Explain a reorganization without implying arbitrary coin creation.
  • Compare full validation and inclusion-based checks.
Your learning map

Three questions to carry into this lesson.

01Explain a reorganization without implying arbitrary coin creation.
02Compare full validation and inclusion-based checks.
Use these goals to guide your reading. Try the paper exercise, then explain the result in your own words.

Competing valid histories can occur

Nodes can temporarily learn about different valid blocks near the tip. If a competing valid chain accumulates greater work, a node may reorganize its accepted history. Transactions from displaced blocks may reappear elsewhere, return to an unconfirmed state or conflict with accepted spends. A reorganization is not permission to violate the node’s monetary or spending rules.

Inclusion proofs answer a narrower question

A lightweight client can use headers and Merkle evidence to check inclusion under particular assumptions. That is different from independently executing all validation rules over the entire chain. The whitepaper discusses the tradeoff. A product should tell users which verification approach it uses rather than borrowing the assurance of a full node it does not operate.

Design state transitions honestly

A payment interface should be able to move from an earlier observation to a corrected state when the underlying chain changes. A confirmation badge hard-coded forever after the first observation is poor accounting. Keep order fulfillment policy distinct from chain observation, and preserve an audit trail of corrections. Do not promise that any single confirmation count makes all attack models impossible.

Your turn / A paper experiment

Practice on paper

A fictional donation was included in a block later displaced by a reorganization. What should a reporting system avoid doing?

I’ve tried it — show the worked answer

It should avoid permanently counting the old inclusion as final without checking the accepted chain. It must reassess the transaction and its settlement state, preserve the correction and avoid treating reappearance as a second donation.

Want to explore with buttons and instant feedback? Try the practice lab ↗

Think it through

Make a choice. Discover why.

Choose an answer and check the explanation. You can retry as often as you like. These are practice questions, not a test of mastery; answers are not saved or sent.

1. Can a greater-work chain force a node to accept invalid inflation?
  • Yes
  • No
Read the explanation

No. The chain must still satisfy that node’s validation rules.

2. Is transaction inclusion the same as full validation?
  • Yes
  • No
Read the explanation

No. The checks and assumptions differ.

One idea to take with you

Build systems that can correct observations when the chain view changes.

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.