GOD DAM IT someone just moved the fucking wallet.. and had to of used the shared K.. the timing is too obvious..
thank you mother fuckers. only 2 people had it both well known on here....
Topic: ECDSA signature R,S,Z values (Read 632 times)
i just want to check this... when its not re-used pub-keys nor anything else which would invalidate it.
from what ive read and seen its a valid attribute.. how about if i say please
lol insert image here ehhh
You're not supposed to calculate RS-ZS, to get the private key if you got two transactions with the same nonce, you must calculate (S1*Z2 - S2*Z1) / (S1*R2 - S2*R1).
See my article about the subject for how this expression is derived.
See my article about the subject for how this expression is derived.
its the utility .. RS-ZS im not using that value.. but okay let me try yours with the same nonce and see what happens, which is K and still is valid
Just a heads-up, this equation calculates the nonce, not the private key. I made a little mistake while writing that post. But the article link should still be correct.
At any time, you can always compute the private key with:
x = (s*k-m)/r
for either message.
Okay i looked over your post... but here is the thing... both sigs pass all tests --> https://rawcdn.githack.com/nlitsme/bitcoinexplainer/0165c8008266606503b460475dfb1750c2dc6282/ecdsacrack.html so if there was something wrong they would fail.
Also your example is relevant ..but its (s1*z2 - s2*z1) / (R1*(S1-S2)) is the same as the formula above IF R1 and R2 are equal then it applies. R does not have to be equal to K to be able to be mapped, just shared by 2 txn generated or not.
since one is 254 and the other 256 and arrive at the same point on K its relevant. Look this also inst my strong suit, those were created on valid pub-key and address compressed... nothing is re-used..
So the rule of thumb that i have seen over all the years here is that K can be traced back to the private key.. If you want to do it or show me it would be awesome, as i would like to recover the wallet.
If i doesn't work then okay... but i have tried to do it again which is impossible to duplicate.
just to balance it, another person states that its a different K its correlating too... ""If K would be the same, "R" should also be the same. ...Because r = k*G"" - but this is not possible as there is only ONE K ... its not as if there is another one which phases in and out on the same bit level.. .
Also they did not have the full 2 examples, as i omitted K .. There are points on both sides im not discounting that but as Albert also said its a mix and match which approach and makes the shared K value i outlined relevant and solvable..
""The signature is then (r,s) and H(M) is the SHA-256 hash of the message (M), and converted into an integer value. The power of -1 is the inverse mod function.
But here is the problem … if the k value (the random value for each signature) is revealed for any of the signatures, an intruder can easily determine the private key using: priv=R-1 x ((k.s)-H(M))
i am no where as involved in this side of the internals,.. and i could be wrong, but to determine that would be to finish it , which is why i asked for some help here, its the end of the road for me as i dont know what the next steps are and would like someone to review it.
I cant post it out in the open on the chance its legitimate.
so how about anyone giving me something that inst going to make me cuss like sailor here changing it or better yet something already made for 2 RSZ 1K recovery
You're not supposed to calculate RS-ZS, to get the private key if you got two transactions with the same nonce, you must calculate (S1*Z2 - S2*Z1) / (S1*R2 - S2*R1).
See my article about the subject for how this expression is derived.
See my article about the subject for how this expression is derived.
its the utility .. RS-ZS im not using that value.. but okay let me try yours with the same nonce and see what happens, which is K and still is valid
Just a heads-up, this equation calculates the nonce, not the private key. I made a little mistake while writing that post. But the article link should still be correct.
At any time, you can always compute the private key with:
x = (s*k-m)/r
for either message.
You're not supposed to calculate RS-ZS, to get the private key if you got two transactions with the same nonce, you must calculate (S1*Z2 - S2*Z1) / (S1*R2 - S2*R1).
See my article about the subject for how this expression is derived.
See my article about the subject for how this expression is derived.
its the utility .. RS-ZS im not using that value.. but okay let me try yours with the same nonce and see what happens, which is K and still is valid
You're not supposed to calculate RS-ZS, to get the private key if you got two transactions with the same nonce, you must calculate (S1*Z2 - S2*Z1) / (S1*R2 - S2*R1).
See my article about the subject for how this expression is derived.
See my article about the subject for how this expression is derived.
Indeed if you figure any relationship betweetn two different signatures from the same publickey you may solve the equation.
Is there a py script or something for this you know of albert?
I have a question... what happens if you derive at the same K value with different RSZ and on 254 and 256 bit...
is that not suppose to occur? does this allow the funds to be spent on the correlating address?
is that not suppose to occur? does this allow the funds to be spent on the correlating address?
For a given pubkey, you will have four possible combos to make a different but equivalent signature for it: X and P-X (unless X >= N - an extremely rare occurence), and Y and -Y.
R is directly derived from X so the only way you'd end up with two R's for the same nonce is if you used the other identical value for X. In a similar vein, you can end up with four different S values if you mix&match X and Y values.
And yes, that would allow the private key to be solved for and its funds to be spent, because solving such an equation is trivial.
edit .... ok ok so the following example with K being the same; would not apply? is it R and S only or K also?
or
do they have another K in common ?... as IF K were the same ; then R should be also?? Because r=k*G ??
Does the example here apply to it being solved?
i keep getting different answers ...
R = 2a6054e8ce59804ea0f17acd9bae77821979db060a68a00495478a131d1f2af4
S = 59ae683a16989880daeb3d5a51db290e0d5df58646096ba9b2f0aea0b3b653b4
Z = df1fef64c3e73a4da4bafe978a7972704ab1d3b00856b9781d766d0e2f88b39c
K = bc813ab951c818377c8ff62e231b513590eeac46209724e3ac3240b331e5e141 253 bits --- being the same
Z/(s-r) b0619c786326bac40967b8c05d8f059139b159774b97963fd9ba1b1a3f14783f
Z/S= 0ccff1a8a20c7894467fcfa5ea954551029b1fa53233d309bcf4cc4c8dc
R/S= 5db046ac0b085437a89db5d3fe929e2bffb2103a17583a1271821fc6734968ef
RS-ZS= 50e0550368fbdba3621de62e14021545235d0010655de6ef345183f72684a013
------------------------------------------------------------------------------
R = ff711fed4c0317d4801f3629032e058b9a071c9188faf3b9d774cb62e56283d0
S = 09bfa67778a2edea3476eb39ddf714b38453285615b738d2936408a80853f8d5
Z = 4c6e87c7ee7dcd84efc9d9db53dc54205018f8d283888ea3697700e4af9e
K = bc813ab951c818377c8ff62e231b513590eeac46209724e3ac3240b331e5e141 256 bits -- being the same
Z/(s-r) bc562f9ce5c0603eac439117824598c37b98ab4d0b0642bb73769f87f4de1169
Z/S= 0f5dee8376c61bd8a11c42b4f4f3e3d6f7be4025cba2fb9ce62b931b00440ec2
R/S= c41ad234c35db01fc5edb73b3792e275dcc31f152ea3de7a57056df491b9a777
RS-ZS= b4bce3b14c97944724d17486429ef4535432ee504deef6300e2dd70d9dad9917598b5
derived from Addresss and compressed pubkey
* this is just a example..
edit: does the bit value matter? what if they were 9bit instead? or has no bearing?
Indeed if you figure any relationship betweetn two different signatures from the same publickey you may solve the equation.
I have a question... what happens if you derive at the same K value with different RSZ and on 254 and 256 bit...
is that not suppose to occur? does this allow the funds to be spent on the correlating address?
is that not suppose to occur? does this allow the funds to be spent on the correlating address?
For a given pubkey, you will have four possible combos to make a different but equivalent signature for it: X and P-X (unless X >= N - an extremely rare occurence), and Y and -Y.
R is directly derived from X so the only way you'd end up with two R's for the same nonce is if you used the other identical value for X. In a similar vein, you can end up with four different S values if you mix&match X and Y values.
And yes, that would allow the private key to be solved for and its funds to be spent, because solving such an equation is trivial.
I have a question... what happens if you derive at the same K value with different RSZ and on 254 and 256 bit...
is that not suppose to occur? does this allow the funds to be spent on the correlating address?
is that not suppose to occur? does this allow the funds to be spent on the correlating address?
User iceland2k14, OP in this topic has not been active for several months. I believe that he forgot about this discussion here already, therefore do not expect him to answer your question here.
You are not a completely new user here, you should definitely check the time of writing the previous post before continuing the discussion.
well i figured if it was anyone who would know .. it would be him.. as he is the auth to the majority of tools revolving around this topic.
also i didnt want to get drowned out either... so thank you for your answer.
who knows maybe he will grace us with his presence again.. edit: also i just want some help with this without it being in a busy thread .. as its a sensitive item...
I have a question... what happens if you derive at the same K value with different RSZ and on 254 and 256 bit...
is that not suppose to occur? does this allow the funds to be spent on the correlating address?
is that not suppose to occur? does this allow the funds to be spent on the correlating address?
User iceland2k14, OP in this topic has not been active for several months. I believe that he forgot about this discussion here already, therefore do not expect him to answer your question here.
You are not a completely new user here, you should definitely check the time of writing the previous post before continuing the discussion.
I have a question... what happens if you derive at the same K value with different RSZ and on 254 and 256 bit...
is that not suppose to occur? does this allow the funds to be spent on the correlating address?
is that not suppose to occur? does this allow the funds to be spent on the correlating address?
There are several possibility to find the Nonce used in RSZ. Forget the usual duplicate R value to solve for Nonce. But if you just consider R value as Xpoint, this can be tried to search using the Pubkey search algo. Where Pubkey = '02' + Xpoint
Other possibilities exists too. And feel free to develop your own.
Other possibilities exists too. And feel free to develop your own.
it is can possible to fine NONCE on R,S,Z value
BSGS Algo is well known and documented.
If you want to code it c# or any of the language, please feel free to go ahead.
If you want to code it c# or any of the language, please feel free to go ahead.
Hello there,
bsgs_GPU.py in your git project : https://github.com/iceland2k14/bsgs/tree/main/v7_gpu_trial
Total sequential search in 1 loop default=10000000000000000
How can I do it in c#. Could you help.
in your project, it finishes the 54 bit range in 15 minutes.
thanks for the answer.
bsgs_GPU.py in your git project : https://github.com/iceland2k14/bsgs/tree/main/v7_gpu_trial
Total sequential search in 1 loop default=10000000000000000
How can I do it in c#. Could you help.
in your project, it finishes the 54 bit range in 15 minutes.
thanks for the answer.
Just in case someone wants to know RSZ more, may be your know already.
(python 2.7)
https://github.com/wobine/blackboard101/blob/master/EllipticCurvesPart5-TheMagic-SigningAndVerifying.py
https://www.youtube.com/watch?v=U2bw_N6kQL8&list=PLzctEq7iZD-7-DgJM604zsndMapn9ff6q&index=19
Sometimes i needed the RSZ values of BTC Signatures for testing and understanding and calculation purposes.
A python3 script RSZ is made available in github.
The script parse the data of rawtx to fetch all the inputs in the transaction and reconstructs the unsigned message for each of them to find the Z value. The result is given as R,S,Z,Pubkey for each of the inputs present in the rawtx data
If txid is given, instead of rawtx then blockchain API is used to fetch the details of rawtx and then R,S,Z is calculated
How to Use:
Output Using the txid
Output Using the rawtx
Limitations (Might Not Work for):
Ideally i might try to Update to include more not working cases, but No Promises
A python3 script RSZ is made available in github.
The script parse the data of rawtx to fetch all the inputs in the transaction and reconstructs the unsigned message for each of them to find the Z value. The result is given as R,S,Z,Pubkey for each of the inputs present in the rawtx data
If txid is given, instead of rawtx then blockchain API is used to fetch the details of rawtx and then R,S,Z is calculated
How to Use:
Code:
python getz_input.py [-h] [-txid TXID] [-rawtx RAWTX]
Output Using the txid
Code:
(base) C:\anaconda3\RSZ>python getz_input.py -txid 82e5e1689ee396c8416b94c86aed9f4fe793a0fa2fa729df4a8312a287bc2d5e
Starting Program...
======================================================================
[Input Index #: 0]
R: 009bf436ce1f12979ff47b4671f16b06a71e74269005c19178384e9d267e50bbe9
S: 00c7eabd8cf796a78d8a7032f99105cdcb1ae75cd8b518ed4efe14247fb00c9622
Z: 9f4503ab6cae01b9fc124e40de9f3ec3cb7a794129aa3a5c2dfec3809f04c354
PubKey: 04e3896e6cabfa05a332368443877d826efc7ace23019bd5c2bc7497f3711f009e873b1fcc03222f118a6ff696efa9ec9bb3678447aae159491c75468dcc245a6c
======================================================================
[Input Index #: 1]
R: 0094b12a2dd0f59b3b4b84e6db0eb4ba4460696a4f3abf5cc6e241bbdb08163b45
S: 07eaf632f320b5d9d58f1e8d186ccebabea93bad4a6a282a3c472393fe756bfb
Z: 94bbf25ba5b93ba78ee017eff80c986ee4e87804bee5770fae5b486f05608d95
PubKey: 04e3896e6cabfa05a332368443877d826efc7ace23019bd5c2bc7497f3711f009e873b1fcc03222f118a6ff696efa9ec9bb3678447aae159491c75468dcc245a6c
Output Using the rawtx
Code:
(base) C:\anaconda3\RSZ>python getz_input.py -rawtx 01000000028370ef64eb83519fd14f9d74826059b4ce00eae33b5473629486076c5b3bf215000000008c4930460221009bf436ce1f12979ff47b4671f16b06a71e74269005c19178384e9d267e50bbe9022100c7eabd8cf796a78d8a7032f99105cdcb1ae75cd8b518ed4efe14247fb00c9622014104e3896e6cabfa05a332368443877d826efc7ace23019bd5c2bc7497f3711f009e873b1fcc03222f118a6ff696efa9ec9bb3678447aae159491c75468dcc245a6cffffffffb0385cd9a933545628469aa1b7c151b85cc4a087760a300e855af079eacd25c5000000008b48304502210094b12a2dd0f59b3b4b84e6db0eb4ba4460696a4f3abf5cc6e241bbdb08163b45022007eaf632f320b5d9d58f1e8d186ccebabea93bad4a6a282a3c472393fe756bfb014104e3896e6cabfa05a332368443877d826efc7ace23019bd5c2bc7497f3711f009e873b1fcc03222f118a6ff696efa9ec9bb3678447aae159491c75468dcc245a6cffffffff01404b4c00000000001976a91402d8103ac969fe0b92ba04ca8007e729684031b088ac00000000
Starting Program...
======================================================================
[Input Index #: 0]
R: 009bf436ce1f12979ff47b4671f16b06a71e74269005c19178384e9d267e50bbe9
S: 00c7eabd8cf796a78d8a7032f99105cdcb1ae75cd8b518ed4efe14247fb00c9622
Z: 9f4503ab6cae01b9fc124e40de9f3ec3cb7a794129aa3a5c2dfec3809f04c354
PubKey: 04e3896e6cabfa05a332368443877d826efc7ace23019bd5c2bc7497f3711f009e873b1fcc03222f118a6ff696efa9ec9bb3678447aae159491c75468dcc245a6c
======================================================================
[Input Index #: 1]
R: 0094b12a2dd0f59b3b4b84e6db0eb4ba4460696a4f3abf5cc6e241bbdb08163b45
S: 07eaf632f320b5d9d58f1e8d186ccebabea93bad4a6a282a3c472393fe756bfb
Z: 94bbf25ba5b93ba78ee017eff80c986ee4e87804bee5770fae5b486f05608d95
PubKey: 04e3896e6cabfa05a332368443877d826efc7ace23019bd5c2bc7497f3711f009e873b1fcc03222f118a6ff696efa9ec9bb3678447aae159491c75468dcc245a6c
Limitations (Might Not Work for):
- Very Old Signatures
- When Witness Data is present in Signatures
- ETH or any other AltCoins
Ideally i might try to Update to include more not working cases, but No Promises
Jump to: