1) Non-push opcodes in the unlocking script (scriptSig) - E…

79b · February 13, 2026

1) Non-push opcodes in the unlocking script (scriptSig)
- Example: scriptSig = OP_TRUE (or OP_ADD 1 1), spending a trivial scriptPubKey like OP_VERIFY or OP_DROP pattern.
- Early Bitcoin: Valid (the interpreter allowed arbitrary opcodes in scriptSig).
- BTC today: Invalid. The SIGPUSHONLY rule requires that scriptSig contain only data pushes during script verification; nodes also enforce it as standardness.
- BCH today: Invalid for the same reason (push-only unlocking scripts are enforced by consensus/validation flags).
- BSV today: Generally invalid under current default rules for version 1 transactions (post-Genesis, BSV enforces “data-only in unlocking scripts” as a consensus rule for typical tx versions). BSV’s Chronicle update introduces version-gated relaxations, but by default you should treat non-push opcodes in scriptSig as invalid on BSV unless you deliberately opt into the new versioned behavior where permitted.