0

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.

1

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 to elements.

txinwitness: 
1. 304402207db22867e47fd73b43d44d2faf51f492c7e13b0356e64928e4ee5ccb8c5654b3022046b569f15fae82c6c9ffe91e98c63004974aab0582e7296ef2cec555fc329ee301
2. 037ef7c159605d43e78d4c1ad53b53e60e46bcc504ad9bca6c33fd889fcc324eea

In Nested-P2WPKH (or in generell 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.

| improve this answer | |
  • 1
    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 Mar 10 at 4:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.