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

Sikh Bitcoin · Advanced · Lesson 21 of 21

Capstone: trace a payment end to end

Build a technically honest verification map.

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 21 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 transaction construction, validation and settlement.
  • Identify the assumptions at each layer.

Choose a fictional transaction

Design a paper payment from an imaginary community treasury to an artist. Give it two inputs, a recipient output, a change output and an explicit fee. Describe the spending policy and whether a PSBT coordinator is involved. Use synthetic amounts and abstract keys; no real addresses, credentials or signing actions are required.

Trace the evidence

Explain what the signer checks, what the broadcasting node observes, what a miner includes and what the receiving wallet verifies. Add a possible replacement and a possible reorganization. If you choose a Lightning alternative, replace the on-chain-per-payment assumptions with channel, routing and settlement conditions. Do not pretend both paths provide identical observations or operational requirements.

Challenge your own account

Ask where an untrusted coordinator, stale node, missing policy backup or misleading interface could create an error. Identify what an independent reviewer can reproduce and what remains dependent on external behavior. The final artifact is a one-page explanation and a list of unresolved assumptions. A strong Bitcoin advocate should be able to explain both the system’s useful guarantees and the places where careful operations remain necessary.

Practice on paper

For inputs of 80,000 and 50,000 sats, a 90,000-sat artist payment and a 1,500-sat fee, compute change and name three independent checks in your map.

Reveal the worked answer

Change is 38,500 sats. Useful independent checks include signer review of outputs and fee, node validation against consensus rules, and recipient reconciliation of the accepted transaction to the invoice. Each verifies a different property.

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 one green checkmark summarize every trust boundary?

  • Yes
  • No
Reveal answer 1

No. Name the check and its scope.

2. Should a technical explainer hide uncertain implementation details?

  • Yes
  • No
Reveal answer 2

No. Label them and identify the evidence needed to resolve them.

Take this with you

Technical depth means being precise about both guarantees and assumptions.

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.