How do I to get the r, S and Z values from a raw transaction (version 2)

Question

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.

Answer 1

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.

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