user135394: 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.

user101191: 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.

135394: <p>What is true sign of transaction in <em>bitcoin testnet</em> (<a href="https://blockstream.info/testnet/tx/c6c232a36395fa338da458b86ff1327395a9afc28c5d2daa4273e410089fd433" rel="nofollow noreferrer">https://blockstream.info/testnet/tx/c6c232a36395fa338da458b86ff1327395a9afc28c5d2daa4273e410089fd433</a>)  :</p>
<p><strong>c6c232a36395fa338da458b86ff1327395a9afc28c5d2daa4273e410089fd433</strong></p>
<p><strong>Original RAW transaction :</strong> <em>0100000001d6ca712f68c4d3003b9558f772463d5b468ed44360184c9628c02e96276901cf000000002f21026d2204a9535443657a88a0724fbd49a0e78d305f50a82f2cc9dd9bea10a6c5cd0c093006020101020101017cacffffffff010000000000000000016a00000000</em></p>
<p>I counted sign as (use this help <a href="https://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx">How to redeem a basic Tx?</a> ) : <em><strong>0xfdf34b9d1e3985d7662022a5ea4ba1def9954570752ca1d5d9b6fc648d5d6061</strong></em>, but ECDSA sign verification fails.</p>
<p>Values :</p>
<p><em>r = 0x1</em></p>
<p><em>s = 0x1</em></p>
<p><em>z = 0xfdf34b9d1e3985d7662022a5ea4ba1def9954570752ca1d5d9b6fc648d5d6061</em></p>
<p><em>pk = { 0x6d2204a9535443657a88a0724fbd49a0e78d305f50a82f2cc9dd9bea10a6c5cd,      0x496fb35210894a4614bd5a2d3f284c7ea6f6f1bd36510e39dcdb4be0d6e0f110 }</em></p>
<p><strong>Transaction uses for signing:</strong></p>
<p><em>0100000001d6ca712f68c4d3003b9558f772463d5b468ed44360184c9628c02e96276901cf0000000017a91458a994e9d5ed9baa03ecfd1137592a90ad3cdfc587ffffffff010000000000000000016a0000000001000000</em></p>
<p>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.</p>
 101191: <p>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.</p>
<p>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.</p>
<p>Read more from Jimmy Song's Programming Bitcoin: <a href="https://learning.oreilly.com/library/view/programming-bitcoin/9781492031482/ch05.html#idm46739596961624" rel="nofollow noreferrer">https://learning.oreilly.com/library/view/programming-bitcoin/9781492031482/ch05.html#idm46739596961624</a></p>
<p>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.</p>
<p>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.</p>
<p>Read more about how P2SH inputs are validated here: <a href="https://learning.oreilly.com/library/view/programming-bitcoin/9781492031482/ch08.html#idm46739591457944" rel="nofollow noreferrer">https://learning.oreilly.com/library/view/programming-bitcoin/9781492031482/ch08.html#idm46739591457944</a></p>
<pre><code>{
   inputs: [
     {
       prev_txid: &quot;cf016927962ec028964c186043d48e465b3d4672f758953b00d3c4682f71cad6&quot;,
       prev_vout: 0,
       script_sig: &quot;21026d2204a9535443657a88a0724fbd49a0e78d305f50a82f2cc9dd9bea10a6c5cd0c093006020101020101017cac&quot;,
       sequence_no: 4294967295
     }
   ],
   lock_time: 0,
   outputs: [{script_pub_key: &quot;6a&quot;, value: 0}],
   version: 1,
   witnesses: nil
 }
</code></pre>
<p>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 <code>093006020101020101017cac</code>.</p>
<pre><code>OP_PUSHBYTES_33 026d2204a9535443657a88a0724fbd49a0e78d305f50a82f2cc9dd9bea10a6c5cd OP_PUSHBYTES_12 093006020101020101017cac
</code></pre>
<p>If we parse this redeem Script, we get:</p>
<pre><code>OP_PUSHBYTES_9 300602010102010101 OP_SWAP OP_CHECKSIG
</code></pre>
<p>There is the signature: <code>300602010102010101</code> Its last byte, <code>01</code> is the SigHash flag for <code>SIGHASH_ALL</code>. The rest, <code>3006020101020101</code> is a DER-encoded signature.</p>
<p>For some reason I can't explain, this signature has (r,s) = (1,1). I don't know why this is valid.</p>
