3

Hi I am learning bitcoin and learning how scripting works and how to use P2PKH. I was wondering how does OP_CHECKSIG work. I want to understand what is the data that the private key signs to create the digital signature itself?

Is there a simple explanation which illustrates how the digital signature is constructed for verification in OP_CHECKSIG? I understand that the Opcode uses the ECDSA algorithm for verifying the signature but I want to understand how the signature is generated for verification?

Pardon me if this is a basic question. Thanks

Improve this question
3

What is signed is a simplified version of the transaction (replacing the scriptSig, since that is what we are creating). There is a lot here so hopefully I covered it all:

 * `version` (4 Bytes) - Transaction format version
 * `flag` (2 Byte Array) - Optional flag, if present, must be 0001, which indicates there is witness data in this transaction
 * `input counter` (Variable Length) - Number of inputs in the transaction represented by a Variable Length Integer.
 * `inputs` (based on Input Counter) - List of all transaction inputs which will be spent and which reference unspent transaction outputs from previous transactions.
 * `output counter` (Variable Length) - Number of outputs in the transaction represented by a Variable Length Integer.
 * `outputs` (based on Output Counter) - List of all transaction outputs where the coins will be sent and which will become unspent transaction outputs to be spent in future transactions.
 * `scriptsig` (variable) - First, a one-byte varint which denotes the length of the scriptSig, then it is temporarily filled with the scriptPubKey of the output we want to redeem.
 * sequence number (4 Bytes) - Used as a relative lock time if transaction version is >= 2. See BIP68.
 * one-byte varint containing the number of outputs in our new transaction
 * 8-byte field (64 bit integer) containing the amount we want to redeem from the specified output (in satoshis)
 * one-byte varint denoting the length of the output script
 * output script
 * `locktime` (4 Bytes) - If non-zero and sequence numbers are < `ffffffff`: it represents either the block height or timestamp when transaction is final.
 * four-byte "hash code type" (1 in our case): 01000000 see [Sighash types][1]

Then, double-SHA256 hash this entire structure and the hash is what is signed. For an example, see https://bitcoin.stackexchange.com/a/5241/60443

Improve this answer
10
  • Thanks that was great! @JBaczuk Also is the way the signature is created differs for different sighash type? Is there a documentation where I can find where and how these transactions are signed? Or if you know could you explain say something like a SIGHASH_ALL|SIGHASH_ANYONECANPAY. How the Unlocking Script signs the inputs?
    – shubham saxena
    Aug 30 '19 at 6:50
  • Yes, see bitcoin.org/en/transactions-guide#signature-hash-types
    – JBaczuk
    Aug 30 '19 at 20:25
  • So from what I have read. The input contains the previous transaction hash, the index and the ScriptPubkey of this input that we are consuming? But is this ScriptPubkey a temporary value which is replaced by some other script? @JBaczuk
    – shubham saxena
    Sep 9 '19 at 10:25
  • No, the input does not contain the scriptpubkey, the scriptsig does while you are signing it, then it is replaced with the actual scriptsig which is a script that satisfies the scriptpubkey. The scriptsig will contain the transaction signature, this is why it is temporarily filled with the scriptpubkey
    – JBaczuk
    Sep 9 '19 at 12:10
  • So that means, I have to replace the scriptPubKey of the input with the actual signature appended with the hash code type and then consequently remove the last 4 bytes? This will be the input that is hashed twice and signed over by the private key? @JBaczuk
    – shubham saxena
    Sep 9 '19 at 12:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.