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

Sikh Bitcoin · Advanced · Lesson 4 of 21

Scripts describe spending conditions

Understand programmability without assuming an account-based model.

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 4 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 locking conditions and satisfying data.
  • Recognize why arbitrary contract assumptions do not transfer.

An output carries a condition

Bitcoin transactions create outputs whose scripts constrain how they may be spent. A later spending transaction supplies the required data. In a simple key-based example, the conditions involve a valid signature for the relevant key. More complex constructions can express combinations such as multiple keys and time constraints.

Execution answers a bounded question

Script evaluation determines whether a proposed spend satisfies the applicable rules. It does not consult an external website to determine whether a meal happened. Bitcoin’s model is different from an application with a mutable account database or a general-purpose EVM contract. Familiar words such as contract can hide important differences in state, execution and available primitives.

Review the whole condition

A diagram saying two signatures required is incomplete if there is also an alternative recovery branch after a delay. Conversely, a script that is elegant mathematically may be difficult to back up or operate with available wallets. Separate what the script permits from what a user interface claims and what the organization intends. This lesson explains conditions; it does not ask you to construct or fund a custom script with real assets.

Practice on paper

A fictional spending policy has one path requiring two keys and another available after a delay. What must a reviewer inspect beyond the phrase “two-key wallet”?

Reveal the worked answer

They must inspect the alternative path, timing conditions, who controls its keys, wallet support and recovery behavior. A summary that omits a valid branch can misrepresent who can ultimately spend.

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 Bitcoin script directly verify that a dinner was served?

  • Yes
  • No
Reveal answer 1

No. That real-world fact is outside the transaction’s own validation data.

2. Does an EVM contract explanation automatically apply to Bitcoin outputs?

  • Yes
  • No
Reveal answer 2

No. Their execution and state models differ.

Take this with you

A spending policy is the complete set of allowed paths.

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.