Difference between revisions of "OP CHECKSIG"

Line 23: Line 23:
 
# 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.
 
# 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.
 
# Any remaining OP_CODESEPARATORS are removed from the subScript.
 
# Any remaining OP_CODESEPARATORS are removed from the subScript.
# A serialisation algorithm is called to produce an input to double SHA256 depending on sighash type. We will describe the SIGHASH_ALL case first:
+
# A serialisation algorithm is called to produce an input to double SHA256 depending on sighash type:
 
## nVersion in <math>TX_{current}</math> (4-byte little endian)
 
## nVersion in <math>TX_{current}</math> (4-byte little endian)
 
## double SHA256 of the serialisation of all input outpoints (32-byte hash)
 
## double SHA256 of the serialisation of all input outpoints (32-byte hash)
*** if ANYONECANPAY flag is set, than this should be a 32-byte zero.
+
### if ANYONECANPAY flag is set, then this should be a 32-byte zero.
 
## double SHA256 of the serialisation of nSequence of all inputs (32-byte hash)
 
## double SHA256 of the serialisation of nSequence of all inputs (32-byte hash)
## the outpoint being spent (32-byte + 4-byte little endian)
+
### 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)
 
## length in bytes of the subScript (big endian)
 
## the subScript
 
## the subScript
Line 34: Line 35:
 
## nSequence of this outpoint (4-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>.)
 
## 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)
 
## nLocktime of the transaction <math>TX_{current}</math> (4-byte little endian)
 
## sighash type of the signature (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.
 
 
 
 
A function called SIGHASH
 
Now depending on the hashtype various things can happen to txCopy, these will be discussed individually. See [[SIGHASH flags]] for more detail.
 
 
 
====SIGHASH_ALL====
 
This SIGHASH flag indicates that the signature will sign all the inputs and all the outputs.
 
 
 
 
 
===Final signature check===
 
 
 
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.
 
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_CHECKSIGVERIFY 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==
 
==References==
 
https://github.com/bitcoin-sv/bitcoin-sv/blob/master/src/script/interpreter.cpp
 
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.

Revision as of 10:53, 20 January 2020

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. 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 to be given here.
  4. Check the public key encoding is of the correct format. Both compressed public key and uncompressed public key can be acceptable. Two examples to be given here.
  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 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 endia)
    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.