What is true sign of transaction in bitcoin testnet (https://blockstream.info/testnet/tx/c6c232a36395fa338da458b86ff1327395a9afc28c5d2daa4273e410089fd433) :


Original RAW transaction : 0100000001d6ca712f68c4d3003b9558f772463d5b468ed44360184c9628c02e96276901cf000000002f21026d2204a9535443657a88a0724fbd49a0e78d305f50a82f2cc9dd9bea10a6c5cd0c093006020101020101017cacffffffff010000000000000000016a00000000

I counted sign as (use this help How to redeem a basic Tx? ) : 0xfdf34b9d1e3985d7662022a5ea4ba1def9954570752ca1d5d9b6fc648d5d6061, but ECDSA sign verification fails.

Values :

r = 0x1

s = 0x1

z = 0xfdf34b9d1e3985d7662022a5ea4ba1def9954570752ca1d5d9b6fc648d5d6061

pk = { 0x6d2204a9535443657a88a0724fbd49a0e78d305f50a82f2cc9dd9bea10a6c5cd, 0x496fb35210894a4614bd5a2d3f284c7ea6f6f1bd36510e39dcdb4be0d6e0f110 }

Transaction uses for signing:


What am I missing or doing wrong? And what is the true value of Z in this transaction and how can it be calculated ? Thanks for the answer.

1 Answer 1


Assuming you are talking about the transaction signatures and not attempting to sign the raw transaction data, I can see a few problems with this method.

First, it is worth understanding what a transaction signature is. A transaction contains signatures for each input, and thus, the signature cannot sign the entire transaction. When a typical (legacy) transaction is signed, the fields where the signatures would go is set to zero, allowing the signatures to be generated. Then these signatures are emplaced in those fields.

Read more from Jimmy Song's Programming Bitcoin: https://learning.oreilly.com/library/view/programming-bitcoin/9781492031482/ch05.html#idm46739596961624

Second, inputs have signatures, not the transaction as a whole. If a transaction spends multiple coins, there will be multiple signatures in the transaction. If a coin locked in a multisig address is being spent, there can even be multiple signatures per input.

Thirdly, this is an irregular transaction. It spends a P2SH input whose redeem script is a P2PK script. But here you can see a breakdown of the transaction's fields.

Read more about how P2SH inputs are validated here: https://learning.oreilly.com/library/view/programming-bitcoin/9781492031482/ch08.html#idm46739591457944

   inputs: [
       prev_txid: "cf016927962ec028964c186043d48e465b3d4672f758953b00d3c4682f71cad6",
       prev_vout: 0,
       script_sig: "21026d2204a9535443657a88a0724fbd49a0e78d305f50a82f2cc9dd9bea10a6c5cd0c093006020101020101017cac",
       sequence_no: 4294967295
   lock_time: 0,
   outputs: [{script_pub_key: "6a", value: 0}],
   version: 1,
   witnesses: nil

The ScriptSig is where the signature (wrapped in some script) can be found. If we decode the ScriptSig, we see a Public Key and a Redeem Script. The Redeem Script is the last 12 bytes of data 093006020101020101017cac.

OP_PUSHBYTES_33 026d2204a9535443657a88a0724fbd49a0e78d305f50a82f2cc9dd9bea10a6c5cd OP_PUSHBYTES_12 093006020101020101017cac

If we parse this redeem Script, we get:


There is the signature: 300602010102010101 Its last byte, 01 is the SigHash flag for SIGHASH_ALL. The rest, 3006020101020101 is a DER-encoded signature.

For some reason I can't explain, this signature has (r,s) = (1,1). I don't know why this is valid.

  • 1
    Thanks a lot for the clarification! The question is what real Z(hash) value was used to sign input 0 of the above transaction and how this Z value was obtained. I gave the transaction in the form in which the Z value is also calculated above and the calculated SHA256(SHA256()) value. But at the same time, the verification of the digital signature turns out to be incorrect. Because of the wrong Z value.
    – bit_user
    Jul 13, 2022 at 19:03
  • Ahh, okay. the z value is derived based on the type of SigHash flag used. The SigHash flag is the last byte of the signature. In this, and most cases, that is 1 for SIGHASH_ALL. read more: river.com/learn/terms/s/sighash-flag or learn.saylor.org/mod/book/view.php?id=36341&chapterid=18919 Jul 14, 2022 at 0:28
  • I've updated the original answer for more in depth explanation. Jul 14, 2022 at 0:31
  • Thank you for your comment! The fact that the values (r=1,s=1) I indicated in the very first message (in the text of the question). There is nothing special about this, since there is a point on the curve with coordinates: (0x01, 0xbde70df51939b94c9c24979fa7dd04ebd9b3572da7802290438af2a681895441). I also used the SIGHASH_ALL flag according to the rules that you gave above, and also led a transaction to calculate the Z value in which the SIGHASH_ALL flag is present.
    – Bit_user
    Jul 14, 2022 at 7:24
  • 0100000001d6ca712f68c4d3003b9558f772463d5b468ed44360184c9628c02e96276901cf0000000017a91458a994e9d5ed9baa03ecfd1137592a90ad3cdfc587ffffffff010000000000000000016a0000000001000000 By hashing sha256(sha256()) this transaction I get Z=0xfdf34b9d1e3985d7662022a5ea4ba1def9954570752ca1d5d9b6fc648d5d6061. But with this Z value, the digital signature verification does not pass, although this signature is valid (because this transaction has been added to the test blockchain and it has a lot of confirmations).
    – Bit_user
    Jul 14, 2022 at 7:24

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.