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

Sikh Bitcoin · Advanced · Lesson 1 of 21

Read the whitepaper as an argument

Follow the problem, assumptions and proposed mechanism.

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

  • Connect double spending to a shared ordering problem.
  • Separate the paper’s technical proposal from later implementations.

Start with the threat

The whitepaper asks how willing parties can transact digitally without making one intermediary the authority over payment history. A signature can establish authorization, but by itself does not reveal whether the same spend was offered elsewhere. The proposal therefore joins signatures with a public ordering mechanism and a way to compare competing histories.

Keep the assumptions visible

The paper analyzes an adversary trying to catch up with an honest chain. Its security discussion depends on assumptions about relative work and behavior. Read those assumptions before repeating the conclusion. The everyday phrase longest chain is best understood here through accumulated proof of work, not merely counting an arbitrary collection of blocks. A node still rejects a chain that violates its validation rules.

Read historically and technically

The document is a foundation, not a current wallet manual. Later improvements, deployed rules and operational experience belong in implementation documentation. When teaching it, annotate each paragraph as problem, mechanism, assumption or consequence. Avoid turning a technical statement about payment history into a guarantee about prices, human governance or charitable outcomes. Strong advocacy becomes more credible when it can explain the limits of its own evidence.

Practice on paper

Why are digital signatures alone insufficient to solve the problem described in the introduction? Write a two-sentence explanation for a technical newcomer.

Reveal the worked answer

A signature shows that the relevant key authorized a spend, but does not independently establish whether a conflicting spend exists. The network needs a shared way to establish which history to accept under its rules.

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 chain selection replace transaction validation?

  • Yes
  • No
Reveal answer 1

No. A candidate history must satisfy validation rules.

2. Is the whitepaper a current step-by-step wallet guide?

  • Yes
  • No
Reveal answer 2

No. It presents the foundational argument; implementations evolved.

Take this with you

Read the assumptions as carefully as the conclusion.

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.