Are these cases from an existing Tx on blockchain or it's from mathematical Tx ?
So far, such a thing has not come across in the transaction, as the field is huge and the probability of getting this result is very small. But, with the correct creation of signatures, this can be easily obtained. And it's even easier to get it by artificially creating signatures, using the formula R = ur * Q + uz * G. For example, for calculation from two public keys and two nonce private keys. The calculation will go to 0. But, as soon as you introduce a little chaos into the ideal, everything will be calculated immediately. 
Topic: relationship between two nonces (Read 265 times)
There are cases when the differences between public keys and (or) nonce are known, but it is impossible to calculate k due to a phenomenon known as “perfect linear dependence”.
Are these cases from an existing Tx on blockchain or it's from mathematical Tx ?
So how to find nonce leak?
3. When you somehow know the mathematical relationship between 2 K, like K2 =K1/2 or K2 = K1 + 1637737337373738373729826362936, whatever, then also PVK can be calculated.
There are cases when the differences between public keys and (or) nonce are known, but it is impossible to calculate k due to a phenomenon known as “perfect linear dependence”.
Yes there are several ways.
1. When same K is used 2 times either in same or different Transaction, its trivial to calculate PVK. Its already extensively exploited.
2. When K values are closeby so that difference can be bruteforced quickly, then also PVK can be calculated.
3. When you somehow know the mathematical relationship between 2 K, like K2 =K1/2 or K2 = K1 + 1637737337373738373729826362936, whatever, then also PVK can be calculated.
4. When you have several Tx and there may be few bits common, either LSB or MSB, then also it's possible to calculate PVK through Lattice reduction. (Check minimum required Tx for Bit Leakage).
5. If the number of Tx is not sufficient for Lattice reduction but there is info about sufficient bit leakage, we could use the same Kangaroo solver approach on the Rvalue of Tx to get K.
6. We could mathematically generate Tx for known Leakage in Privatkeys and then try to bruteforce. For example Puzzle 130 is know to have a 126 bits Leakage in PVK. So several derived Tx from it can be considered for bruteforce.
7. There could be more which I am not aware of yet.
The main point is, there is no 100% sureshot method which will work on generic Tx. All different approaches either need some vulnerability or prior info or some bruteforce.
1. When same K is used 2 times either in same or different Transaction, its trivial to calculate PVK. Its already extensively exploited.
2. When K values are closeby so that difference can be bruteforced quickly, then also PVK can be calculated.
3. When you somehow know the mathematical relationship between 2 K, like K2 =K1/2 or K2 = K1 + 1637737337373738373729826362936, whatever, then also PVK can be calculated.
4. When you have several Tx and there may be few bits common, either LSB or MSB, then also it's possible to calculate PVK through Lattice reduction. (Check minimum required Tx for Bit Leakage).
5. If the number of Tx is not sufficient for Lattice reduction but there is info about sufficient bit leakage, we could use the same Kangaroo solver approach on the Rvalue of Tx to get K.
6. We could mathematically generate Tx for known Leakage in Privatkeys and then try to bruteforce. For example Puzzle 130 is know to have a 126 bits Leakage in PVK. So several derived Tx from it can be considered for bruteforce.
7. There could be more which I am not aware of yet.
The main point is, there is no 100% sureshot method which will work on generic Tx. All different approaches either need some vulnerability or prior info or some bruteforce.
iceland2k14 I can't believe you're here. Very pleased to meet you.
You said in one of your articles, "There are several ways to find a nonce." Is there anything else you can suggest?
You said in one of your articles, "There are several ways to find a nonce." Is there anything else you can suggest?
Nonce or k is an ephemeral private key in signing that should be created randomly which means there shouldn't be any kind of relationships between any two k values that were created correctly.
The only way you would ever find any relationship is if you already know nonce values (you created them yourself) or the implementation used to create them is broken which is a very rare case.
The only way you would ever find any relationship is if you already know nonce values (you created them yourself) or the implementation used to create them is broken which is a very rare case.
K values used in Signature are kept secret as privatkeys. To find the relationship between 2 nonces the only possibility is to try bruteforce.
I had a sript in my rsz repo which extracts all Tx for an address and tries to solve for K and PrivatKeys if the distance between any 2 K values are small (ex. less than 2 billion).
I had a sript in my rsz repo which extracts all Tx for an address and tries to solve for K and PrivatKeys if the distance between any 2 K values are small (ex. less than 2 billion).
Hello friends.
How can we solve the relationship between the two nonces used in the bitcoin transfer signature? Does anyone have information about this? Or what formulas do you use to find the K value?
How can we solve the relationship between the two nonces used in the bitcoin transfer signature? Does anyone have information about this? Or what formulas do you use to find the K value?
Jump to: