Locking and unlocking
Each unspent output contains a locking program. A spending transaction supplies the data required by that program, commonly a signature and public key or witness data.
Validation executes the relevant script rules and accepts the input only when the required conditions evaluate successfully.
A deliberately limited language
Script avoids unbounded loops and is intentionally narrow. This helps every node execute validation deterministically with bounded resource rules.
From templates to advanced conditions
Common address types represent standard script templates. Multisignature, timelocks and Taproot script paths can express richer authorization while remaining subject to consensus and policy limits.
Visual recap
Evaluating a spend
The previous output defines the condition; the new transaction provides evidence.
Locate UTXO
Read locking script
Supply witness data
Execute stack
True or false
Key vocabulary
Terms worth knowing
- ScriptPubKey
- The locking program attached to an output that defines its spending condition.
- Witness
- Data supplied by a spender to satisfy a SegWit output's spending condition.
- Opcode
- An operation interpreted by Bitcoin's deliberately limited scripting system.
Worked example
Spending a signature-locked output
An output commits to a public-key condition. A later transaction supplies a signature and public information needed to satisfy it.
- 1Locate the previous output and its locking condition
- 2Build the spending transaction
- 3Produce a signature for the required transaction digest
- 4Execute the relevant script rules
- 5Accept only if evaluation succeeds and all other rules pass
Bitcoin ownership is implemented as the ability to satisfy spending conditions, not as a name attached to a coin.
Common misconceptions
What learners often get wrong
Misconception
Bitcoin Script is a general-purpose smart-contract language.
More accurate
It is intentionally constrained, non-Turing-complete and designed for predictable validation.
Misconception
A valid script result makes the whole transaction valid.
More accurate
Nodes also check input existence, amounts, locktimes, encoding and every other applicable consensus rule.
Try it yourself
Describe a 2-of-3 spending condition in plain language.
- Name the three authorised public keys
- Set the threshold to two
- List three valid signer combinations
- Explain why one signature fails
- Identify the wallet-policy data needed for recovery
Use fictional values and public information only. Never enter seed words, private keys or other wallet secrets into a learning exercise.
Key takeaways
- Outputs contain spending conditions, not account balances.
- Input data proves that a condition is satisfied.
- Script is deterministic and intentionally constrained.
- Script behavior depends on the output and witness version.
Lesson recap
Check what you learned
Reveal each model answer, then honestly mark whether you understood it or need another review.
1 of 3
Recall
Where are the conditions for spending bitcoin recorded?
References
