Three questions, three boundaries

1. Which bytes are instructions?
2. What is left on the stack?
3. What bytes did the signature commit to?

This is P-256/HASH256 course code, not Bitcoin consensus validation.

Cursor trace

02 76 aa 76: push literal 76aa, then DUP.

The aa byte is data. Next cursor after the push is 3.

P2PKH-lite stack

[sig,pub] → DUP → [sig,pub,pub]

HASH256 → push expected → EQUALVERIFY → [sig,pub]

CHECKSIG pops pubkey then signature; leaves 01 or 00.

Two kinds of failure

• EQUALVERIFY mismatch: immediate failure.
• CHECKSIG mismatch: pushes 00 and continues.
• Final success: nonempty stack, top has any nonzero byte.

A later push can cover CHECKSIG's false value in this generic machine.

Inspect the digest

H(tx.ID || uint32_le(index) || lockingScript)

The function does not recompute ID from outputs. Changing an output while keeping ID does not change this digest.

Reconstruct independently

Trace 01 07 76 88 through execution and the final truth test.

Then explain why signature verification alone does not prove UTXO validity.