1

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

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:

0100000001d6ca712f68c4d3003b9558f772463d5b468ed44360184c9628c02e96276901cf0000000017a91458a994e9d5ed9baa03ecfd1137592a90ad3cdfc587ffffffff010000000000000000016a0000000001000000

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.

bit_user
  • 11
  • 2

1 Answers1

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:

OP_PUSHBYTES_9 300602010102010101 OP_SWAP OP_CHECKSIG

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.

Sachin Meier
  • 652
  • 3
  • 11
  • 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 '22 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: https://river.com/learn/terms/s/sighash-flag/ or https://learn.saylor.org/mod/book/view.php?id=36341&chapterid=18919 – Sachin Meier Jul 14 '22 at 00:28
  • I've updated the original answer for more in depth explanation. – Sachin Meier Jul 14 '22 at 00: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 '22 at 07: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 '22 at 07:24
  • I just can't understand why the z value I'm calculating is incorrect? Where I made a mistake. – Bit_user Jul 14 '22 at 07:24
  • Hi Bit_user, Stack Exchange is not a forum, it's a question and answer platform. Please do not post other answer posts to reply to answer posts, each answer post must address the question independently. Each topic is based on a single question. Depending on the scope of follow-up questions, either please create a comment on the answer post to request clarification, edit your original question to clarify what your question was, or create a new topic. If your update substantially changes the question, it's better to ask a new question than to invalidate answers that fit the original question. – Murch Jul 15 '22 at 15:14