OP CHECKSIG - Revision history

Jnewbery: Corrections to the sighash algorithm, and a note that sighash is calculated differently for segwit scripts.

2019-01-16T21:44:21Z

Corrections to the sighash algorithm, and a note that sighash is calculated differently for segwit scripts.

Jcomeauictx: /* How it works */ there is generally no sig in subscript to delete. obsolete information if it ever was correct.

2018-01-17T19:35:49Z

How it works: there is generally no sig in subscript to delete. obsolete information if it ever was correct.

← Older revision		Revision as of 19:35, 17 January 2018
Line 14:		Line 14:
	# 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.		# 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 instruction from the most recently parsed OP_CODESEPARATOR (last one in script) to the end of the script. If there is no OP_CODESEPARATOR the entire script becomes the subscript (hereby referred to as subScript)		# A new subscript is created from the instruction from the most recently parsed OP_CODESEPARATOR (last one in script) to the end of the script. If there is no OP_CODESEPARATOR the entire script becomes the subscript (hereby referred to as subScript)
	# The sig is deleted from subScript.		# The sig is deleted from subScript, if present (it is ''not standard'' to have a signature in an input script of a transaction)
	# All OP_CODESEPARATORS are removed from subScript		# All OP_CODESEPARATORS are removed from subScript
	# The hashtype is removed from the last byte of the sig and stored		# The hashtype is removed from the last byte of the sig and stored

Jcomeauictx: clarifying what's meant by "input", not an address but a transaction hash

2018-01-16T03:33:00Z

clarifying what's meant by "input", not an address but a transaction hash

← Older revision		Revision as of 03:33, 16 January 2018
Line 96:		Line 96:

	input 0:		input 0:
	c9 97 a5 e5 6e 10 41 02 input ~~address~~ hash		c9 97 a5 e5 6e 10 41 02 input transaction hash (from block 9)
	fa 20 9c 6a 85 2d d9 06		fa 20 9c 6a 85 2d d9 06
	60 a2 0b 2d 9c 35 24 23		60 a2 0b 2d 9c 35 24 23
	ed ce 25 85 7f cd 37 04		ed ce 25 85 7f cd 37 04
	00 00 00 00 input index		00 00 00 00 input index (index of txout in block 9 that's being spent)

	48 size of script (var_uint)		48 size of script (var_uint)

Bitaps: How it works -> signature format -> last byte is hashtype: (previus explanation was unclear and have context of bitcoin source c++ function CheckSig)

2015-08-05T13:49:06Z

How it works -> signature format -> last byte is hashtype: (previus explanation was unclear and have context of bitcoin source c++ function CheckSig)

← Older revision		Revision as of 13:49, 5 August 2015
Line 12:		Line 12:
	Firstly always this (the default) procedure is applied:		Firstly always this (the default) procedure is applied:
	[[File:Bitcoin_OpCheckSig_InDetail.png\|thumb\|right\|Signature verification process of the default procedure]]		[[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. ~~If the~~ hash-type value is ~~0, then it is replaced by the last_byte of the signature. Then the~~ last byte of the ~~signature is always deleted~~.		# 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 instruction from the most recently parsed OP_CODESEPARATOR (last one in script) to the end of the script. If there is no OP_CODESEPARATOR the entire script becomes the subscript (hereby referred to as subScript)		# A new subscript is created from the instruction from the most recently parsed OP_CODESEPARATOR (last one in script) to the end of the script. If there is no OP_CODESEPARATOR the entire script becomes the subscript (hereby referred to as subScript)
	# The sig is deleted from subScript.		# The sig is deleted from subScript.

Taras at 15:47, 19 July 2015

2015-07-19T15:47:12Z

← Older revision		Revision as of 15:47, 19 July 2015
Line 296:		Line 296:
	[[Category:Developer]]		[[Category:Developer]]
	{{DISPLAYTITLE:OP_CHECKSIG}}		{{DISPLAYTITLE:OP_CHECKSIG}}
	~~{{good}}~~

Jayemar: Clarified some of the grammar use in the explanation

2015-07-02T23:54:02Z

Clarified some of the grammar use in the explanation

← Older revision		Revision as of 23:54, 2 July 2015
Line 1:		Line 1:
	'''OP_CHECKSIG''' is [[Script\|script]] opcode used to verify that the signature for a tx input is valid. OP_CHECKSIG expects two values to be on the stack~~, these~~ are, in order of stack depth, the public key and the signature of the script. These two values are normally obtained by running the scriptSig script of the transaction input we are attempting to validate. ~~After the~~ scriptSig script is run ~~the script is deleted~~ but the stack is left as is, ~~and then~~ the scriptPubKey script from the previous transaction output that is now being spent is run, generally concluding in an OP_CHECKSIG.		'''OP_CHECKSIG''' is [[Script\|script]] opcode used to verify that the signature for a tx input is valid. OP_CHECKSIG expects two values to be on the stack. These are, in order of stack depth, the public key and the signature of the script. 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.

	The standard scriptPubKey checks that the public key (actually a hash of) is a particular value, and that OP_CHECKSIG passes.		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.		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 ==		== Parameters ==

	In addition to the script code itself ~~and the stack parameters~~, to operate OP_CHECKSIG needs to know the current transaction and the index of current transaction input.		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.

	== How it works ==		== How it works ==

Taras at 05:13, 10 January 2015

2015-01-10T05:13:54Z

← Older revision		Revision as of 05:13, 10 January 2015
Line 1:		Line 1:
	OP_CHECKSIG is [[Script\|script]] opcode used to verify that the signature for a tx input is valid. OP_CHECKSIG expects two values to be on the stack, these are, in order of stack depth, the public key and the signature of the script. These two values are normally obtained by running the scriptSig script of the transaction input we are attempting to validate. After the scriptSig script is run the script is deleted but the stack is left as is, and then the scriptPubKey script from the previous transaction output that is now being spent is run, generally concluding in an OP_CHECKSIG.		'''OP_CHECKSIG''' is [[Script\|script]] opcode used to verify that the signature for a tx input is valid. OP_CHECKSIG expects two values to be on the stack, these are, in order of stack depth, the public key and the signature of the script. These two values are normally obtained by running the scriptSig script of the transaction input we are attempting to validate. After the scriptSig script is run the script is deleted but the stack is left as is, and then the scriptPubKey script from the previous transaction output that is now being spent is run, generally concluding in an OP_CHECKSIG.

	The standard scriptPubKey checks that the public key (actually a hash of) is a particular value, and that OP_CHECKSIG passes.		The standard scriptPubKey checks that the public key (actually a hash of) is a particular value, and that OP_CHECKSIG passes.
Line 295:		Line 295:
	[[Category:Technical]]		[[Category:Technical]]
	[[Category:Developer]]		[[Category:Developer]]
			{{DISPLAYTITLE:OP_CHECKSIG}}
			{{good}}

Amiller: typo

2014-07-29T21:50:05Z

typo

← Older revision		Revision as of 21:50, 29 July 2014
Line 41:		Line 41:
	<li> If hashtype & SIGHASH_ANYONECANPAY then apply the SIGHASH_ANYONECANPAY-procedure		<li> If hashtype & SIGHASH_ANYONECANPAY then apply the SIGHASH_ANYONECANPAY-procedure
	</ol>		</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 ~~types~~ in the (main) block chain (and is handled like SIGHASH_ALL).		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) ===		=== Hashtype SIGHASH_ALL (default) ===

Philipkd: sp

2014-04-07T20:24:26Z

← Older revision		Revision as of 20:24, 7 April 2014
Line 1:		Line 1:
	OP_CHECKSIG is [[Script\|script]] opcode used to verify that the signature for a tx input is valid. OP_CHECKSIG expects two values to be on the stack, these are, in order of stack depth, the public key and the signature of the script. These two values are normally obtained by running the scriptSig script of the transaction input we are attempting to validate. After the scriptSig script is run the script is deleted but the stack is left as is, and then ~~then~~ scriptPubKey script from the previous transaction output that is now being spent is run, generally concluding in an OP_CHECKSIG.		OP_CHECKSIG is [[Script\|script]] opcode used to verify that the signature for a tx input is valid. OP_CHECKSIG expects two values to be on the stack, these are, in order of stack depth, the public key and the signature of the script. These two values are normally obtained by running the scriptSig script of the transaction input we are attempting to validate. After the scriptSig script is run the script is deleted but the stack is left as is, and then the scriptPubKey script from the previous transaction output that is now being spent is run, generally concluding in an OP_CHECKSIG.

	The standard scriptPubKey checks that the public key (actually a hash of) is a particular value, and that OP_CHECKSIG passes.		The standard scriptPubKey checks that the public key (actually a hash of) is a particular value, and that OP_CHECKSIG passes.

Petertodd: /* Procedure for Hashtype SIGHASH_SINGLE */ typo

2014-02-04T04:15:04Z

Procedure for Hashtype SIGHASH_SINGLE: typo

← Older revision		Revision as of 04:15, 4 February 2014
Line 62:		Line 62:
	Think of this as "sign '''one''' of the outputs-- I don't care where the other outputs go".		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 outputs ~~than inputs~~.		Note: The transaction that uses SIGHASH_SINGLE type of signature should not have more inputs than outputs.
	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]		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]

← Older revision		Revision as of 21:44, 16 January 2019
Line 1:		Line 1:
			''This article describes the operation of OP_CHECKSIG in non-segwit scripts. The hash digest for OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, OP_CHECKMULTISIGVERIFY in segwit scripts is calculated differently, as described in [https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki BIP 143].''

	'''OP_CHECKSIG''' is [[Script\|script]] opcode used to verify that the signature for a tx input is valid. OP_CHECKSIG expects two values to be on the stack. These are, in order of stack depth, the public key and the signature of the script. 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.		'''OP_CHECKSIG''' is [[Script\|script]] opcode used to verify that the signature for a tx input is valid. OP_CHECKSIG expects two values to be on the stack. These are, in order of stack depth, the public key and the signature of the script. 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.

Line 13:		Line 15:
	[[File:Bitcoin_OpCheckSig_InDetail.png\|thumb\|right\|Signature verification process of the default procedure]]		[[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.		# 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 ~~instruction~~ from the most recently parsed OP_CODESEPARATOR ~~(last one in script)~~ to the end of the script. If there is no OP_CODESEPARATOR the entire script becomes the ~~subscript (hereby referred to as~~ subScript)		# 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
	# ~~The~~ sig is deleted from subScript, if present (it is ''not standard'' to have a signature in an input script of a transaction)		# 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)
	# ~~All~~ OP_CODESEPARATORS are removed from subScript		# Any remaining OP_CODESEPARATORS are removed from subScript
	# The hashtype is removed from the last byte of the sig and stored		# 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)		# A copy is made of the current transaction (hereby referred to txCopy)
Line 68:		Line 70:

	# The txCopy input vector is resized to a length of one.		# The txCopy input vector is resized to a length of one.
	# The subScript ~~(lead in by its length as a var-integer encoded!~~) is set as the first and only member of this vector.		# The current transaction input (with scriptPubKey modified to subScript) is set as the first and only member of this vector.

	Think of this as "Let other people add inputs to this transaction, I don't care where the rest of the bitcoins come from."		Think of this as "Let other people add inputs to this transaction, I don't care where the rest of the bitcoins come from."