Each OP_CHECKSIG
and OP_CHECKSIGVERIFY
is counted as 1 sigop.
Each OP_CHECKMULTISIG
or OP_CHECKMULTISIGVERIFY
, is counted as 20 sigops if they are found in an output or scriptSig and not part of a redeemScript, i.e. not P2SH.
If OP_CHECKMULTISIG
or OP_CHECKMULTISIGVERIFY
are in a redeemScript (i.e. it's P2SH), then the number of sigops is the number of public keys in the multisig redeemScript. If there is more than 16 public keys, then it is always accounted as 20.
For non-segwit inputs, these numbers are multiplied by 4, so 4 sigops for OP_CHECKSIG
and OP_CHECKSIGVERIFY
, and 80 sigops for OP_CHECKMULTISIG
and OP_CHECKMULTISIGVERIFY
.
However segwit inputs don't use these scripts explicitly. So a segwit input where the witness program is version 0 and the program is 20 bytes (i.e. P2WPKH), the number of sigops is 1. If the witness program is version 0 and the program is 32 bytes (i.e. P2WSH), the witnessScript is interpreted and its sigop count is as above as that uses the opcodes explicitly.
So in your example transaction, the input spends a P2SH-P2WPKH and the output has an OP_CHECKSIG
. Since the input is P2WPKH, it is counted as 1 sigop. The output as an OP_CHECKSIG
, so that's another 1 sigop. However because that output is not a segwit output, its number of sigops is multiplied by 4. Thus the output is actually 4 sigops. Summing those is 1 + 4 = 5 sigops in the entire transaction.