I was checking OP_CHECKSIG today and see that the signature of a transaction will be computed from the transaction but copying the ScriptPubKey from the transaction referenced as input into the SigKey of the new transaction.

I guess this has something to do with tx malleability, but I cannot see in what case this would really help? The tx-inputs already reference IDs that can be changed implying malleability.

It would only make sense to include the inputs ScriptPubKeys if it would be possible to keep an ID while changing its ScriptPubKey (which is not possible), or am I missing something?

I am refering to this graphic Step 7 + 8: https://en.bitcoin.it/w/images/en/7/70/Bitcoin_OpCheckSig_InDetail.png

2 Answers 2


AFAIK this was a design choice by Satoshi originally that is unnecessary for the reasons stated in the OP. There is a comment about this in bitcoinj

  // Set the input to the script of its output. Bitcoin Core does this but the step has no obvious purpose as
  // the signature covers the hash of the prevout transaction which obviously includes the output script
  // already. Perhaps it felt safer to him in some way, or is another leftover from how the code was written.

However, it should be noted that there is value in signing particular parts of the previous transaction. Segwit just implemented a new transaction signature algorithm to the cover the amount of satoshis a input is spending from a given output.


The signature should cover as much data, as possible.

And it is bad idea to sign the same data for all input scripts if the transaction redeems several outputs from one transaction

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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