> For the complete documentation index, see [llms.txt](https://hub.bsvblockchain.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hub.bsvblockchain.org/wiki/bitcoin-script-and-opcodes/script/op-checksig.md).

# OP CHECKSIG

**OP\_CHECKSIG** is an opcode that verifies an ECDSA signature. It takes two inputs from the stack, a public key (on top of the stack) and an ECDSA signature in its DER\_CANONISED format concatenated with sighash flags. It outputs true or false on the stack based on whether the signature check passes or fails.

1. Parameters In addition to the stack parameters, OP\_CHECKSIG needs to have
2. the current transaction TX\_{current},
3. the index of the transaction input in which the signature is checked i,
4. the scriptPubKey in which this OP\_CHECKSIG belongs previousScriptPubKey, and
5. the value in satoshi that the outpoint represents amount. Note that previousScriptPubKey is from previous transaction, in which the output is spent in current transaction.
6. How it works In short, OP\_CHECKSIG calls a function called "sighash" which produces a hash value of the serialised transaction. (For legacy sighash algorithm, please click here.) The hash value is the message on which the signature is verified. The signature and the public key involved in the verification are obtained from the stack. In detail:
7. Check the stack size is not less than 2.
8. The public key and the signature are popped as the top 2 items of the stack.
9. Check the signature encoding is of the correct format \[]. An example: 47304402205a2b556c71ee1c12d8e0b460c3446aeca0e3ee71b7bc11c6ddd3da8beeec99c60220783a1f0c0158674df8904022ec30fab5154c4fc4c7e8467086f0204cc8e16cbb01, where 47 indicates number of bytes in hex (71 in decimal) of the signature including 1 byte of sighash flag at the end, the next 46 bytes (70 in decimal) are the ECDSA signature (r,s), the last byte is the sighash flag "ALL".
10. Check the public key encoding is of the correct format. Both compressed public key and uncompressed public key can be acceptable. An example: 210220798b9772a8ae06d13027e6f501d09ea07f6dfc4b7afc3db3a6d6c57bf24239, where 21 indicates the number of bytes in hex of the public key, 02 indicates this is a compressed public and the y-coordinate is an even number, the rest is the value of the x-coordinate of the public key. Note that if the second byte is 04, then it indicates that the public key is given in its uncompressed form.
11. A new subScript is created from the previousScriptPubKey. The subScript starts from the most recent OP\_CODESEPARATOR (the one just before the OP\_CHECKSIG that is executed here) to the end of the previousScriptPubKey. If there is no OP\_CODESEPARATOR, the entire previousScriptPubKey becomes the subScript.
12. Any remaining OP\_CODESEPARATORS are removed from the subScript.
13. A serialisation algorithm (sighash) is called to produce an input to double SHA256 depending on sighash type:
14. nVersion in TX\_{current} (4-byte little endian).
15. double SHA256 of the serialisation of all input outpoints (32-byte hash).
16. if ANYONECANPAY flag is set, then this should be a 32-byte zero.
17. double SHA256 of the serialisation of nSequence of all inputs (32-byte hash).
18. if ANYONECANPAY flag is set, then this should be a 32-byte zero.
19. the outpoint being spent (32-byte for transaction ID + 4-byte little endian for index).
20. length in bytes of the subScript (big endian).
21. the subScript.
22. amount (8-byte little endian).
23. nSequence of this outpoint (4-byte little endian).
24. double SHA256 of the serialization of all output amount (8-byte little endian) with scriptPubKey (These are the outputs in TX\_{current}.).
25. If SINGLE flag is set and the input index is smaller than the number of outputs, then this should be the double SHA256 of the output with scriptPubKey of the same index as the input.
26. If NONE flag is set, then this should be a 32-byte zero.
27. nLocktime of the transaction TX\_{current} (4-byte little endian).
28. sighash type of the signature (4-byte little endian).
29. The serialisation in bytes from the step above will be fed to double SHA256 to produce the 32-byte message. This message is used to check the ECDSA signature, together with the public key and the signature obtained from the stack. Note that the secp256k1 elliptic curve is used for the verification with the given public key.
30. Return values OP\_CHECKSIG will push true to the stack if the check passed, false otherwise. OP\_CHECKSIGVERIFY leaves nothing on the stack but will cause the script validation to fail immediately if the check does not pass.
31. References <https://github.com/bitcoin-sv/bitcoin-sv/blob/master/src/script/interpreter.cpp> See SIGHASH flags for more detail on the effect of combinations of flags.
32. Attribution This content is based on content sourced from <https://en.bitcoin.it/wiki/OP\\_CHECKSIG> under [Creative Commons Attribution 3.0](https://creativecommons.org/licenses/by/3.0/). Although it may have been extensively revised and updated, we acknowledge the original authors.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://hub.bsvblockchain.org/wiki/bitcoin-script-and-opcodes/script/op-checksig.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
