R S Z

[Kapacabana]

I would be grateful for the help. Does anyone have a utility or link where you can get R S Z from bitcoin transactions?

2coin periodically does not work 

Maybe there is a solution in Python from raw?

[HeRetiK]

I haven't tested it, but here's a short Python snipped I found that extracts R and S from a transaction's ScriptSig

Code:

from pyasn1.codec.der import decoder as asn1der
int_value = asn1der.decode(asn_sig.decode('hex')[1:]) #asn_sig is the scriptsig hex
long(int_value[0][0]) #R Value in int form
long(int_value[0][1]) #S Value in int form

Calculating the Z value is a bit more complicated but this thread (and its stackexchange link) should point you in the right direction:
https://bitcointalk.org/index.php?topic=1796142.0
https://bitcoin.stackexchange.com/questions/32628/redeeming-a-raw-transaction-step-by-step-example-required/32695#32695

[elisacat]

R S Z is dead in the water. It only works on P2KH addresses (i.e. most addresses that begin with '1') and practically the moment this was discovered it has been wiped clean. Tried it for all the lost addresses from 2010 to 2014 (120k total) and nothing. And as far as im aware it's not possible to calculate R S Z for P2SH addresses.

[achow101]

R S Z is dead in the water. It only works on P2KH addresses (i.e. most addresses that begin with '1') and practically the moment this was discovered it has been wiped clean. Tried it for all the lost addresses from 2010 to 2014 (120k total) and nothing. And as far as im aware it's not possible to calculate R S Z for P2SH addresses.

That's not true and it is clear you don't understand how Bitcoin works.

Every single signature contains an R and s value. Those two values are what define a signature. P2SH scriptSigs generally do have signatures but their locations are dependent on the script being executed. You essentially need a script interpreter to find them. There are scripts that don't have signatures, but those are few and far between. Z can be calculated for any input independent of signatures, although there are actually multiple possible values and getting the right one for verifying a signature depends on the sighash type found at the end of the signature.


There is no single R, s, and Z values for a transaction. Each signature has a R and s value. There are multiple possible Z values for a signature, depending on the sighash type. Each input also has a different Z values regardless of sighash type as each input requires different data to be hashed.

I don't know of any tool that computes these automatically for every signature, but it's pretty easy to do it yourself. Each ECDSA signatures is a DER encoded signature with the ASN.1 syntax

Code:

ECDSA-Full-R ::= SEQUENCE {
    r ECPoint,
    s INTEGER
}

and then immediately appended by a single byte for the sighash type.

Within a scriptSig or scriptWitness, signatures are pretty easy to spot. Because DER encoding follows some pretty specific rules, the beginning of each signature is fairly distinct. Each signature begins with either 30440220 or 3045022100 and is either 71 or 72 bytes long. You can then decode the signature as just described to get the R and s values.

Z is the hash of the message being signed. It is specifically the double sha256 of the message. For non-segwit inputs, the sighash algorithm is described in the stack exchange thread linked by HeRetiK. For segwit inputs, it is described by BIP 143