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

Sikh Bitcoin · Advanced · Lesson 17 of 21

Reorganizations and lightweight evidence

Understand why history observations have different strengths.

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 17 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

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

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.

Practice on paper

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

Reveal 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.

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. Can a greater-work chain force a node to accept invalid inflation?

  • Yes
  • No
Reveal answer 1

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

2. Is transaction inclusion the same as full validation?

  • Yes
  • No
Reveal answer 2

No. The checks and assumptions differ.

Take this 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.