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

Sikh Bitcoin · Advanced · Lesson 2 of 21

Hashes and Merkle commitments

Learn what a compact commitment establishes—and what it does not.

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 2 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 Merkle inclusion proof conceptually.
  • Distinguish integrity from truth and availability.

A commitment binds data

A cryptographic hash maps data to a fixed-size result. In Bitcoin, hashes connect block headers and organize transaction commitments. Change the underlying data and the corresponding commitment normally changes. A hash does not contain an explanation of the data, and it is not encryption that can be reversed to recover the original content.

A tree makes a short path useful

A Merkle tree combines hashes in pairs until one root remains. A proof can supply the neighboring hashes needed to reconstruct the root from a particular leaf. This establishes inclusion relative to a trusted or independently verified root. It does not, by itself, validate the included transaction’s spending conditions or prove that the root belongs to the accepted chain.

Apply the boundary to service records

Suppose an organization publishes a hash of a kitchen report. A matching copy later shows that the content agrees with that commitment. It does not prove that meals were served, that the report was honest or that the private evidence will remain available. If the input is predictable, a hash may also be guessable. Keep human verification, storage availability and cryptographic integrity as separate questions in an audit.

Practice on paper

A report hash matches a file, but the file contains an inflated meal count. Which property passed and which remains unproven?

Reveal the worked answer

Integrity relative to the published commitment passed: it is the committed content. The accuracy of the meal count remains unproven. A witness, reconciliation process and accountable review are still required.

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 Merkle proof alone establish every transaction rule was followed?

  • Yes
  • No
Reveal answer 1

No. Inclusion is narrower than full validation.

2. Is hashing a private file equivalent to encrypting it?

  • Yes
  • No
Reveal answer 2

No. A hash is a commitment; it does not provide general confidentiality or recoverability.

Take this with you

A commitment protects consistency, not the truth of an assertion.

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.