<p><s>Your question is somewhat unclear. I presume you are using Bitcoin Core and want to extract the <code>r</code> and <code>S</code> values from the ECDSA signature(s) in your raw transaction. I don't know what you mean by &quot;sig Z&quot;.</s> The edited question is clearer now. I learned about the Z-value only after answering the question and thus don't address it here.</p>
<p>Bitcoin Core offers a <code>decoderawtransaction</code> RPC that you can use to decode the transaction into JSON.</p>
<pre><code>bitcoin-cli decoderawtransaction 0200000000010177858f84b8534b69d5ce161ce709854f18d3a37b607abf570f301eb3d6e0d2520100000017160014f8513401ea5e9dcd57597e8a736f162572d19079feffffff020f68a5000000000017a914d55600283b297e12a0a8e1a92da7c03c0bcb6c528780412942000000001976a914ed5268cb6853e1934f5ec3c1eb637e1ac8ca5fa688ac0247304402207db22867e47fd73b43d44d2faf51f492c7e13b0356e64928e4ee5ccb8c5654b3022046b569f15fae82c6c9ffe91e98c63004974aab0582e7296ef2cec555fc329ee30121037ef7c159605d43e78d4c1ad53b53e60e46bcc504ad9bca6c33fd889fcc324eea00000000
{
  &quot;txid&quot;: &quot;de527fc755b4307c1f615cceda469c0a8057b0f29e73f86b543a98ce5d978462&quot;,
  &quot;hash&quot;: &quot;08b7d919d467558638a7f50e8011a3dfe62769d7f01a35d5b87b66712fe62740&quot;,
  &quot;version&quot;: 2,
  &quot;size&quot;: 249,
  &quot;vsize&quot;: 168,
  &quot;weight&quot;: 669,
  &quot;locktime&quot;: 0,
  &quot;vin&quot;: [
    {
      &quot;txid&quot;: &quot;52d2e0d6b31e300f57bf7a607ba3d3184f8509e71c16ced5694b53b8848f8577&quot;,
      &quot;vout&quot;: 1,
      &quot;scriptSig&quot;: {
        &quot;asm&quot;: &quot;0014f8513401ea5e9dcd57597e8a736f162572d19079&quot;,
        &quot;hex&quot;: &quot;160014f8513401ea5e9dcd57597e8a736f162572d19079&quot;
      },
      &quot;txinwitness&quot;: [
        &quot;304402207db22867e47fd73b43d44d2faf51f492c7e13b0356e64928e4ee5ccb8c5654b3022046b569f15fae82c6c9ffe91e98c63004974aab0582e7296ef2cec555fc329ee301&quot;,
        &quot;037ef7c159605d43e78d4c1ad53b53e60e46bcc504ad9bca6c33fd889fcc324eea&quot;
      ],
      &quot;sequence&quot;: 4294967294
    }
  ],
  &quot;vout&quot;: [
    {
      &quot;value&quot;: 0.10840079,
      &quot;n&quot;: 0,
      &quot;scriptPubKey&quot;: {
        &quot;asm&quot;: &quot;OP_HASH160 d55600283b297e12a0a8e1a92da7c03c0bcb6c52 OP_EQUAL&quot;,
        &quot;hex&quot;: &quot;a914d55600283b297e12a0a8e1a92da7c03c0bcb6c5287&quot;,
        &quot;reqSigs&quot;: 1,
        &quot;type&quot;: &quot;scripthash&quot;,
        &quot;addresses&quot;: [
          &quot;3M92sq9ssFaNbEwF47uteVKJsbw125juS7&quot;
        ]
      }
    },
    {
      &quot;value&quot;: 11.10000000,
      &quot;n&quot;: 1,
      &quot;scriptPubKey&quot;: {
        &quot;asm&quot;: &quot;OP_DUP OP_HASH160 ed5268cb6853e1934f5ec3c1eb637e1ac8ca5fa6 OP_EQUALVERIFY OP_CHECKSIG&quot;,
        &quot;hex&quot;: &quot;76a914ed5268cb6853e1934f5ec3c1eb637e1ac8ca5fa688ac&quot;,
        &quot;reqSigs&quot;: 1,
        &quot;type&quot;: &quot;pubkeyhash&quot;,
        &quot;addresses&quot;: [
          &quot;1NdqsNEXYx9RnpoPqdkfW7hmZiDuX8BrgK&quot;
        ]
      }
    }
  ]
}
</code></pre>
<p>From the JSON response you can tell that you transaction has one input and two outputs. The transaction has a Nested-P2WPKH input and a P2SH and P2PKH output.
You'll find the ECDSA signature in the input. Since the input spends a SegWit output the signature is a witness element (in the JSON a part of <code>txinwitness</code>).</p>
<p>The witness contains two elements.</p>
<pre><code>txinwitness: 
1. 304402207db22867e47fd73b43d44d2faf51f492c7e13b0356e64928e4ee5ccb8c5654b3022046b569f15fae82c6c9ffe91e98c63004974aab0582e7296ef2cec555fc329ee301
2. 037ef7c159605d43e78d4c1ad53b53e60e46bcc504ad9bca6c33fd889fcc324eea
</code></pre>
<p>In Nested-P2WPKH (or in general all script templates from the P2PKH family) the first witness element is the ECDSA signature and the second is the corresponding public key. All newer ECDSA signatures (since the activation of BIP-66 in summer 2015) must be strictly DER encoded. For more information on the DER-encoding see for example: <a href="https://bitcoin.stackexchange.com/a/12556/63817">Why the signature is always 65 (1+32+32) bytes long?</a></p>
<p>Decoding the DER encoded ECDSA signature (first witness element) yields:</p>
<pre><code>DER marker:       30
Sig length:       44
r-value marker:   02
r-value length:   20 (32 byte)
r-value:          7db22867e47fd73b43d44d2faf51f492c7e13b0356e64928e4ee5ccb8c5654b3
S-value marker:   02
S-value length:   20 (32 byte)
S-value:          46b569f15fae82c6c9ffe91e98c63004974aab0582e7296ef2cec555fc329ee3
SigHash:          01
</code></pre>
<p>Both the <code>r-value</code> and the <code>S-value</code> are big-endian integers.</p>

CC BY-SA 4.0
2020-03-10T04:36:13.260Z
I believer `Z` is what some people call the integer calculated from hash of the message in ECDSA algorithm. ie. double SHA256 of the modified transaction.
Coding Enthusiast
CC BY-SA 4.0
2020-03-09T21:03:43.183Z
2021-07-26T10:08:15.100Z
2021-07-26T10:08:15.100Z
0xb10c
<p>To Add onto the previous answer by 0xb10c, Z is the signature hash. It is the hash of the message being signed, and for a transaction, that is the hash of the transaction with empty ScriptSigs. For Witness transactions, this is the hash of the transaction, as the Scriptsig is already empty.</p>

CC BY-SA 4.0
2020-10-23T16:49:33.980Z
2020-10-23T16:49:33.980Z
Sachin Meier
<p>For example I have this raw transaction</p>

<pre><code>0200000000010177858f84b8534b69d5ce161ce709854f18d3a37b607abf570f301eb3d6e0d2520100000017160014f8513401ea5e9dcd57597e8a736f162572d19079feffffff020f68a5000000000017a914d55600283b297e12a0a8e1a92da7c03c0bcb6c528780412942000000001976a914ed5268cb6853e1934f5ec3c1eb637e1ac8ca5fa688ac0247304402207db22867e47fd73b43d44d2faf51f492c7e13b0356e64928e4ee5ccb8c5654b3022046b569f15fae82c6c9ffe91e98c63004974aab0582e7296ef2cec555fc329ee30121037ef7c159605d43e78d4c1ad53b53e60e46bcc504ad9bca6c33fd889fcc324eea00000000
</code></pre>

<p>How do I extract the r, S and Z values from the signature? </p>

<p>I'd be happy about a step-by-step explanation.</p>

<bitcoin-core><signature><ecdsa>
How do I to get the r, S and Z values from a raw transaction (version 2)
Aivar
# How do I to get the r, S and Z values from a raw transaction (version 2)

(Asked by: username_0 on 2020-03-09)

For example I have this raw transaction
0200000000010177858f84b8534b69d5ce161ce709854f18d3a37b607abf570f301eb3d6e0d2520100000017160014f8513401ea5e9dcd57597e8a736f162572d19079feffffff020f68a5000000000017a914d55600283b297e12a0a8e1a92da7c03c0bcb6c528780412942000000001976a914ed5268cb6853e1934f5ec3c1eb637e1ac8ca5fa688ac0247304402207db22867e47fd73b43d44d2faf51f492c7e13b0356e64928e4ee5ccb8c5654b3022046b569f15fae82c6c9ffe91e98c63004974aab0582e7296ef2cec555fc329ee30121037ef7c159605d43e78d4c1ad53b53e60e46bcc504ad9bca6c33fd889fcc324eea00000000

How do I extract the r, S and Z values from the signature? 
I'd be happy about a step-by-step explanation.

**Tags:** bitcoin-core, signature, ecdsa


---

## 2 answers

### Answer by username_1 on 2020-03-09. Score: 2

Your question is somewhat unclear. I presume you are using Bitcoin Core and want to extract the r and S values from the ECDSA signature(s) in your raw transaction. I don't know what you mean by "sig Z". The edited question is clearer now. I learned about the Z-value only after answering the question and thus don't address it here.
Bitcoin Core offers a decoderawtransaction RPC that you can use to decode the transaction into JSON.
bitcoin-cli decoderawtransaction 0200000000010177858f84b8534b69d5ce161ce709854f18d3a37b607abf570f301eb3d6e0d2520100000017160014f8513401ea5e9dcd57597e8a736f162572d19079feffffff020f68a5000000000017a914d55600283b297e12a0a8e1a92da7c03c0bcb6c528780412942000000001976a914ed5268cb6853e1934f5ec3c1eb637e1ac8ca5fa688ac0247304402207db22867e47fd73b43d44d2faf51f492c7e13b0356e64928e4ee5ccb8c5654b3022046b569f15fae82c6c9ffe91e98c63004974aab0582e7296ef2cec555fc329ee30121037ef7c159605d43e78d4c1ad53b53e60e46bcc504ad9bca6c33fd889fcc324eea00000000
{
  "txid": "de527fc755b4307c1f615cceda469c0a8057b0f29e73f86b543a98ce5d978462",
  "hash": "08b7d919d467558638a7f50e8011a3dfe62769d7f01a35d5b87b66712fe62740",
  "version": 2,
  "size": 249,
  "vsize": 168,
  "weight": 669,
  "locktime": 0,
  "vin": [
    {
      "txid": "52d2e0d6b31e300f57bf7a607ba3d3184f8509e71c16ced5694b53b8848f8577",
      "vout": 1,
      "scriptSig": {
        "asm": "0014f8513401ea5e9dcd57597e8a736f162572d19079",
        "hex": "160014f8513401ea5e9dcd57597e8a736f162572d19079"
      },
      "txinwitness": [
        "304402207db22867e47fd73b43d44d2faf51f492c7e13b0356e64928e4ee5ccb8c5654b3022046b569f15fae82c6c9ffe91e98c63004974aab0582e7296ef2cec555fc329ee301",
        "037ef7c159605d43e78d4c1ad53b53e60e46bcc504ad9bca6c33fd889fcc324eea"
      ],
      "sequence": 4294967294
    }
  ],
  "vout": [
    {
      "value": 0.10840079,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_HASH160 d55600283b297e12a0a8e1a92da7c03c0bcb6c52 OP_EQUAL",
        "hex": "a914d55600283b297e12a0a8e1a92da7c03c0bcb6c5287",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "3M92sq9ssFaNbEwF47uteVKJsbw125juS7"
        ]
      }
    },
    {
      "value": 11.10000000,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 ed5268cb6853e1934f5ec3c1eb637e1ac8ca5fa6 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914ed5268cb6853e1934f5ec3c1eb637e1ac8ca5fa688ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "1NdqsNEXYx9RnpoPqdkfW7hmZiDuX8BrgK"
        ]
      }
    }
  ]
}

From the JSON response you can tell that you transaction has one input and two outputs. The transaction has a Nested-P2WPKH input and a P2SH and P2PKH output.
You'll find the ECDSA signature in the input. Since the input spends a SegWit output the signature is a witness element (in the JSON a part of txinwitness).
The witness contains two elements.
txinwitness: 
1. 304402207db22867e47fd73b43d44d2faf51f492c7e13b0356e64928e4ee5ccb8c5654b3022046b569f15fae82c6c9ffe91e98c63004974aab0582e7296ef2cec555fc329ee301
2. 037ef7c159605d43e78d4c1ad53b53e60e46bcc504ad9bca6c33fd889fcc324eea

In Nested-P2WPKH (or in general all script templates from the P2PKH family) the first witness element is the ECDSA signature and the second is the corresponding public key. All newer ECDSA signatures (since the activation of BIP-66 in summer 2015) must be strictly DER encoded. For more information on the DER-encoding see for example: Why the signature is always 65 (1+32+32) bytes long?
Decoding the DER encoded ECDSA signature (first witness element) yields:
DER marker:       30
Sig length:       44
r-value marker:   02
r-value length:   20 (32 byte)
r-value:          7db22867e47fd73b43d44d2faf51f492c7e13b0356e64928e4ee5ccb8c5654b3
S-value marker:   02
S-value length:   20 (32 byte)
S-value:          46b569f15fae82c6c9ffe91e98c63004974aab0582e7296ef2cec555fc329ee3
SigHash:          01

Both the r-value and the S-value are big-endian integers.

> **Comments:**
> **username_2**: I believer `Z` is what some people call the integer calculated from hash of the message in ECDSA algorithm. ie. double SHA256 of the modified transaction.  

---

### Answer by username_3 on 2020-10-23. Score: 2

To Add onto the previous answer by username_1, Z is the signature hash. It is the hash of the message being signed, and for a transaction, that is the hash of the transaction with empty ScriptSigs. For Witness transactions, this is the hash of the transaction, as the Scriptsig is already empty.


---

