<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>

CC BY-SA 4.0
2022-07-13T19:03:00.223Z
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
CC BY-SA 4.0
2022-07-14T00:28:55.390Z
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
CC BY-SA 4.0
2022-07-14T00:31:22.087Z
I've updated the original answer for more in depth explanation.
Sachin Meier
CC BY-SA 4.0
2022-07-14T07:24:21.200Z
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
CC BY-SA 4.0
2022-07-14T07:24:21.200Z
0100000001d6ca712f68c4d3003b9558f772463d5b468ed44360184c9628c02e96276901cf0000000017a91458a994e9d5ed9baa03ecfd1137592a90ad3cdfc587ffffffff010000000000000000016a00000000**01000000**

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
CC BY-SA 4.0
2022-07-14T07:24:21.200Z
I just can't understand why the z value I'm calculating is incorrect? Where I made a mistake.
Bit_user
CC BY-SA 4.0
2022-07-15T15:14:21.553Z
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
CC BY-SA 4.0
2022-07-13T07:50:06.237Z
2022-07-14T00:32:16.993Z
2022-07-14T00:32:16.993Z
Sachin Meier
<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>

<ecdsa>
ECDSA sign of transaction
bit_user
# ECDSA sign of transaction

(Asked by: username_0 on 2022-07-03)

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?](https://bitcoin.stackexchange.com/questions/3374/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.

**Tags:** ecdsa


---

## 1 answers

### Answer by username_1 on 2022-07-13. Score: 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.

> **Comments:**
> **username_0**: 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.  
> **username_1**: 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  
> **username_1**: I've updated the original answer for more in depth explanation.  
> **username_2**: 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.  
> **username_2**: 0100000001d6ca712f68c4d3003b9558f772463d5b468ed44360184c9628c02e96276901cf0000000017a91458a994e9d5ed9baa03ecfd1137592a90ad3cdfc587ffffffff010000000000000000016a00000000**01000000**  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).  
> **username_2**: I just can't understand why the z value I'm calculating is incorrect? Where I made a mistake.  
> **username_3**: Hi username_2, 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.  

---

