TERM_DEF // MODULE_6_SIGNATURES / OP_CHECKSIG
OP_CHECKSIG
OP_CHECKSIG. Verify an ECDSA signature against a public key.
OP_CHECKSIG pops a public key (top) and a signature (second) from the stack, verifies the ECDSA signature against the serialized spending transaction, and pushes 1 (valid) or 0 (invalid). In production this requires the full transaction context. In the Stack simulator, a fixed test-vector pair is used to demonstrate the mechanics without real transaction data.
This page sits in the Module 6 — Signatures section — Vocabulary introduced in the Signatures module. Read on for what it is, why it exists, how it works under the hood, and what to watch out for.
OP_CHECKSIG pops a public key (top) and a signature (second) from the stack, verifies the ECDSA signature against the serialized spending transaction, and pushes 1 (valid) or 0 (invalid). In production this requires the full transaction context. In the Stack simulator, a fixed test-vector pair is used to demonstrate the mechanics without real transaction data.
This page sits in the Module 6 — Signatures section — Vocabulary introduced in the Signatures module. Read on for what it is, why it exists, how it works under the hood, and what to watch out for.
WHAT_OP_CHECKSIG_IS
OP_CHECKSIG — at a glance
MODULE 6
OP_CHECKSIG is a cryptographic component of Bitcoin. Verify an ECDSA signature against a public key. Like every cryptographic building block in Bitcoin, it is fundamentally a piece of math — not a feature provided by a server, not a permission granted by an authority, but a deterministic function that any machine can compute and any other machine can verify.
OP_CHECKSIG pops a public key (top) and a signature (second) from the stack, verifies the ECDSA signature against the serialized spending transaction, and pushes 1 (valid) or 0 (invalid). In production this requires the full transaction context. In the Stack simulator, a fixed test-vector pair is used to demonstrate the mechanics without real transaction data.
Why it exists
DESIGN
Bitcoin has no central authority to vouch for ownership, prove identity, or guarantee that a message has not been tampered with. Cryptography fills all three roles. OP_CHECKSIG exists because the alternative — trusting a third party with custody, signatures, or random number generation — would re-introduce exactly the single points of failure Bitcoin was designed to eliminate. The security of every coin in existence depends on these primitives behaving as advertised.
HOW_IT_WORKS
Mechanism
HOW IT WORKS
The mechanism rests on a one-way function: easy to compute forward, computationally infeasible to reverse. For signature schemes that asymmetry comes from the elliptic-curve discrete logarithm problem on the secp256k1 curve; for hash functions like SHA-256 it comes from collision-resistance. OP_CHECKSIG is built on top of these primitives and inherits their security: every node/">full node can independently verify a result in microseconds, but no attacker can fabricate a fake one in any realistic amount of time, even with all the computers on Earth working together.
1. Generate or receive the input bytes (a private key, a message, a public key, a signature — depending on the operation).
2. Apply the cryptographic primitive — typically built on SHA-256, RIPEMD-160, secp256k1, or Schnorr/ECDSA.
3. Encode the result in the expected form: 32-byte hash, 33-byte compressed pubkey, 64-byte Schnorr signature, ~71-byte DER ECDSA signature, etc.
4. Verifiers worldwide re-run the same computation against the public inputs to confirm authenticity — no shared secret required.
WORKED_EXAMPLE
OP_CHECKSIG — example values
EXAMPLE
concept : OP_CHECKSIG
role : Verify an ECDSA signature against a public key.
basis : secp256k1 / SHA-256 / RIPEMD-160 — Bitcoin's three cryptographic primitives
verify : every full node re-runs the math against public inputs
forge : computationally infeasible (security in bits ≥ 128)
KEY_PROPERTIES
ONE-WAY
Easy to compute forward in microseconds; infeasible to reverse even with planetary compute resources.
COLLISION-RESISTANT
Finding two distinct inputs that produce the same output requires more work than has ever been done on Earth.
PUBLIC-VERIFIABLE
Anyone can check a signature/hash against public data — no shared secret needed for verification.
COMMON_PITFALLS
Things that catch people out
PITFALLS
- Never reuse a signing nonce — a single nonce reuse leaks the private key permanently and irretrievably.
- Never generate keys with weak randomness (timestamps, user input, Math.random) — predictable seeds have drained millions in past incidents.
- Never paste secrets into a web form, screenshot, or cloud note — anywhere they leave your control they may be copied silently.
- Treat OP_CHECKSIG like nuclear material: handle it, store it, and dispose of it deliberately.
RELATED_CONCEPTS
Other terms from Module 6 — Signatures — click any to read its page:
TERMINOLOGY_INDEX
TERMINOLOGY
OP_CHECKSIG
Verify an ECDSA signature against a public key.
ECDSA
Elliptic Curve Digital Signature Algorithm — used to sign Bitcoin transactions.
DER encoding
Distinguished Encoding Rules — the binary format for ECDSA signatures.