Difference between revisions of "OP CHECKSIG"

 
(22 intermediate revisions by 3 users not shown)
Line 1: Line 1:
=DISCLAIMER=
+
'''OP_CHECKSIG''' is an opcode that verifies an [[Elliptic Curve Digital Signature Algorithm| 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.
This article is a direct copy of the article at https://en.bitcoin.it/w/index.php?title=OP_CHECKSIG and has not been checked for correctness or edited.
 
24 September 2019
 
Expected review by: 15 October 2019
 
  
  
'''OP_CHECKSIG''' is an opcode used to verify that the [[Digital Signatures (ECDSA) | ECDSA signature]] in a transaction input is valid. OP_CHECKSIG expects two values to be on the stack, the public key (on the top of the stack) and the signature. These two values are normally obtained by running the scriptSig script of the transaction input we are attempting to validate. The scriptSig script is deleted after it is run, but the stack is left as is.  Then, the scriptPubKey script from the previous transaction output that is now being spent is run, generally concluding in an OP_CHECKSIG.
+
== Parameters ==
 
 
The standard scriptPubKey checks that the public key (actually a hash of) is a particular value, and that OP_CHECKSIG passes.
 
 
 
For normal transaction inputs, if the creator of the current transaction can successfully create a ScriptSig signature that uses the right public key for the ScriptPubKey of the transaction output they are attempting to spend, that transaction input is considered valid.
 
  
== Parameters ==
+
In addition to the stack parameters, OP_CHECKSIG needs to have
 +
# the current transaction <math>TX_{current}</math>,
 +
# the [[index]] of the transaction input in which the signature is checked <math>i</math>,
 +
# the scriptPubKey in which this OP_CHECKSIG belongs <math>previousScriptPubKey</math>, and
 +
# the value in satoshi that the outpoint represents <math>amount</math>.
  
In addition to the stack parameters and the script code itself, in order to operate correctly OP_CHECKSIG needs to know the current transaction and the index of current transaction input.
+
Note that <math>previousScriptPubKey</math> is from previous transaction, in which the output is spent in current transaction.  
  
 
== How it works ==
 
== How it works ==
Firstly always this (the default) procedure is applied:
+
In short, OP_CHECKSIG calls a function called "sighash" which produces a hash value of the serialised transaction. (For legacy sighash algorithm, please click [[Legacy Sighash Algorithm | 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.
[[File:Bitcoin_OpCheckSig_InDetail.png|thumb|right|Signature verification process of the default procedure]]
 
# the public key and the signature are popped from the stack, in that order. Signature format is [<DER signature> <1 byte hash-type>]. Hashtype value is last byte of the sig.
 
# A new subScript is created from the scriptCode (the scriptCode is the actually executed script - either the scriptPubKey for non-segwit, non-P2SH scripts, or the redeemscript in non-segwit P2SH scripts). The script from the immediately after the most recently parsed OP_CODESEPARATOR to the end of the script is the subScript. If there is no OP_CODESEPARATOR the entire script becomes the subScript
 
# Any occurrences of sig are deleted from subScript, if present (it is ''not standard'' to have a signature in an input script of a transaction)
 
# Any remaining OP_CODESEPARATORS are removed from subScript
 
# The hashtype is removed from the last byte of the sig and stored
 
# A copy is made of the current transaction (hereby referred to txCopy)
 
# The scripts for all transaction inputs in txCopy are set to empty scripts (exactly 1 byte 0x00)
 
# The script for the current transaction input in txCopy is set to subScript (lead in by its length as a var-integer encoded!)
 
 
 
Now depending on the hashtype various things can happen to txCopy, these will be discussed individually.
 
 
 
'''Hashtype Values (from script.h):'''
 
{|class="wikitable"
 
! Name !! Value
 
|-
 
| SIGHASH_ALL || 0x00000001
 
|-
 
| SIGHASH_NONE || 0x00000002
 
|-
 
| SIGHASH_SINGLE || 0x00000003
 
|-
 
| SIGHASH_ANYONECANPAY || 0x00000080
 
|}
 
 
 
<ol>
 
<li> If (hashtype&31) = SIGHASH_NONE then apply the SIGHASH_NONE-procedure
 
<li> If (hashtype&31) = SIGHASH_SINGLE then apply the SIGHASH_SINGLE-procedure
 
<li> If hashtype & SIGHASH_ANYONECANPAY then apply the SIGHASH_ANYONECANPAY-procedure
 
</ol>
 
Hence, hashtype SIGHASH_ANYONECANPAY may be applied also after any other hashtype-procedure<ref>[http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.1/bitcoin-0.7.1-linux.tar.gz file src/src/script.cpp in bitcoin-0.7.1]</ref>. Besides the four listed hashtypes only a hashtype of value 0 appears a few times in the (main) block chain (and is handled like SIGHASH_ALL).
 
 
 
=== Hashtype SIGHASH_ALL (default) ===
 
 
 
No special further handling occurs in the default case.  Think of this as "sign '''all''' of the outputs." Which is already done by the default procedure.
 
 
 
=== Procedure for Hashtype SIGHASH_NONE ===
 
 
 
# The output of txCopy is set to a vector of zero size.
 
# All other inputs aside from the current input in txCopy have their nSequence index set to zero
 
 
 
Think of this as "sign '''none''' of the outputs-- I don't care where the bitcoins go."
 
 
 
=== Procedure for Hashtype SIGHASH_SINGLE ===
 
 
 
# The output of txCopy is resized to the size of the current input index+1.
 
# All other txCopy outputs aside from the output that is the same as the current input index are set to a blank script and a value of (long) -1.
 
# All other txCopy inputs aside from the current input are set to have an nSequence index of zero.
 
 
 
Think of this as "sign '''one''' of the outputs-- I don't care where the other outputs go".
 
  
Note: The transaction that uses SIGHASH_SINGLE type of signature should not have more inputs than outputs.
+
In detail:
However if it does (because of the pre-existing implementation), it shall not be rejected, but instead for every "illegal" input (meaning: an input that has an index bigger than the maximum output index) the node should still verify it, though assuming the hash of 0000000000000000000000000000000000000000000000000000000000000001 [https://bitcointalk.org/index.php?topic=260595.0]
 
  
=== Procedure for Hashtype SIGHASH_ANYONECANPAY ===
+
# Check the stack size is not less than 2.
 
+
# The public key and the signature are popped as the top 2 items of the stack.
# The txCopy input vector is resized to a length of one.
+
# Check the signature encoding is of the correct format [<DER signature><hashtype>]. 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".
# The current transaction input (with scriptPubKey modified to subScript) is set as the first and only member of this vector.
+
# 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.
 
+
# A new subScript is created from the <math>previousScriptPubKey</math>. 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 <math>previousScriptPubKey</math>. If there is no OP_CODESEPARATOR, the entire <math>previousScriptPubKey</math> becomes the subScript.
Think of this as "Let other people add inputs to this transaction, I don't care where the rest of the bitcoins come from."
+
# Any remaining OP_CODESEPARATORS are removed from the subScript.
 
+
# A serialisation algorithm (sighash) is called to produce an input to double SHA256 depending on sighash type:
===Final signature check===
+
## nVersion in <math>TX_{current}</math> (4-byte little endian).
 
+
## double SHA256 of the serialisation of all input outpoints (32-byte hash).
An array of bytes is constructed from the serialized txCopy appended by four bytes for the hash type. This array is sha256 hashed twice, then the public key is used to check the supplied signature against the hash.
+
### if ANYONECANPAY flag is set, then this should be a 32-byte zero.
The secp256k1 elliptic curve is used for the verification with the given public key.
+
## double SHA256 of the serialisation of nSequence of all inputs (32-byte hash).
 +
### if ANYONECANPAY flag is set, then this should be a 32-byte zero.
 +
## the outpoint being spent (32-byte for transaction ID + 4-byte little endian for index).
 +
## length in bytes of the subScript (big endian).
 +
## the subScript.
 +
## <math>amount</math> (8-byte little endian).
 +
## nSequence of this outpoint (4-byte little endian).
 +
## double SHA256 of the serialization of all output amount (8-byte little endian) with scriptPubKey (These are the outputs in <math>TX_{current}</math>.).
 +
### 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.
 +
### If NONE flag is set, then this should be a 32-byte zero.
 +
## nLocktime of the transaction <math>TX_{current}</math> (4-byte little endian).
 +
## sighash type of the signature (4-byte little endian).
 +
# 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.
  
 
== Return values ==
 
== Return values ==
  
 
OP_CHECKSIG will push true to the stack if the check passed, false otherwise.
 
OP_CHECKSIG will push true to the stack if the check passed, false otherwise.
OP_CHECKSIG_VERIFY leaves nothing on the stack but will cause the script eval to fail immediately if the check does not pass.
+
OP_CHECKSIGVERIFY leaves nothing on the stack but will cause the script validation to fail immediately if the check does not pass.
  
 +
==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.
  
==References==
+
==Attribution==
<references/>
+
This content is based on content sourced from https://en.bitcoin.it/wiki/OP_CHECKSIG under [https://creativecommons.org/licenses/by/3.0/ Creative Commons Attribution 3.0]. Although it may have been extensively revised and updated, we acknowledge the original authors.
 
 
[[Category:Technical]]
 
[[Category:Developer]]
 
{{DISPLAYTITLE:OP_CHECKSIG}}
 

Latest revision as of 03:26, 22 April 2022

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.


Parameters

In addition to the stack parameters, OP_CHECKSIG needs to have

  1. the current transaction ,
  2. the index of the transaction input in which the signature is checked ,
  3. the scriptPubKey in which this OP_CHECKSIG belongs , and
  4. the value in satoshi that the outpoint represents .

Note that is from previous transaction, in which the output is spent in current transaction.

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:

  1. Check the stack size is not less than 2.
  2. The public key and the signature are popped as the top 2 items of the stack.
  3. Check the signature encoding is of the correct format [<DER signature><hashtype>]. 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".
  4. 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.
  5. A new subScript is created from the . 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 . If there is no OP_CODESEPARATOR, the entire becomes the subScript.
  6. Any remaining OP_CODESEPARATORS are removed from the subScript.
  7. A serialisation algorithm (sighash) is called to produce an input to double SHA256 depending on sighash type:
    1. nVersion in (4-byte little endian).
    2. double SHA256 of the serialisation of all input outpoints (32-byte hash).
      1. if ANYONECANPAY flag is set, then this should be a 32-byte zero.
    3. double SHA256 of the serialisation of nSequence of all inputs (32-byte hash).
      1. if ANYONECANPAY flag is set, then this should be a 32-byte zero.
    4. the outpoint being spent (32-byte for transaction ID + 4-byte little endian for index).
    5. length in bytes of the subScript (big endian).
    6. the subScript.
    7. (8-byte little endian).
    8. nSequence of this outpoint (4-byte little endian).
    9. double SHA256 of the serialization of all output amount (8-byte little endian) with scriptPubKey (These are the outputs in .).
      1. 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.
      2. If NONE flag is set, then this should be a 32-byte zero.
    10. nLocktime of the transaction (4-byte little endian).
    11. sighash type of the signature (4-byte little endian).
  8. 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.

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.

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.

Attribution

This content is based on content sourced from https://en.bitcoin.it/wiki/OP_CHECKSIG under Creative Commons Attribution 3.0. Although it may have been extensively revised and updated, we acknowledge the original authors.