How does Script decide whether an output can be spent?

How does the mechanism work?

Script works with a stack of byte strings. Data pushes place values on the stack; opcodes inspect or transform stack items. Some opcodes compare values, some check hashes and others verify signatures. Successful evaluation must satisfy the rules for the relevant spending construction. Legacy scripts, version-0 witness scripts and Taproot scripts do not share every detail.

A familiar public-key-hash condition duplicates a supplied public key, hashes it, checks the hash against the output’s commitment and then verifies a signature. These operations connect the revealed key with the condition set by the earlier output. Merely putting a signature somewhere in the transaction does not establish that it matches the required key or signed message.

Addresses help interfaces construct standard output scripts. Script remains the mechanism that states spending conditions. A script-hash output commits to another script, which the spender later reveals and satisfies. That extra level means the visible receiving address need not list every signer, delay or alternative encoded in the eventual spending condition.

Stack values are encoded byte strings even when an explanation displays them as convenient integers. Numeric opcodes interpret their arguments under specific encoding and size rules. A hand-written expression that looks sensible in ordinary arithmetic can fail those rules or behave differently under a different script version. For learning, draw the stack before and after each opcode and name which values it consumes. For real transaction construction, consult the exact specification and tested tooling. This distinction lets a small arithmetic example explain execution without suggesting that it covers signature hashing, script-version changes or every consensus limit on an actual spend.

How do the protocol numbers work in an example?

Begin with a deliberately non-payment arithmetic illustration: OP_2 OP_3 OP_ADD OP_5 OP_EQUAL. The first two opcodes push the integers 2 and 3. OP_ADD removes them and pushes 5. OP_5 pushes another 5. OP_EQUAL compares the top items and leaves true. This shows stack evaluation without creating a real destination or requiring a secret.

Now inspect a real witness script shape: OP_0 followed by a push of a 20-byte public-key hash. Its serialized output script is 22 bytes: a version opcode, a length byte and the program. Spending this version-0 key-hash output supplies the signature and public key in the witness. The rules reconstruct and evaluate the appropriate signature-checking condition.

The arithmetic example is not a safe wallet template. Anyone could satisfy an output with an unconditional public arithmetic result. The distinction matters: a script evaluating to true is useful only if the condition corresponds to the authority you intended. A node enforces the written condition, not an explanation of what its author hoped it would mean.