connection between two nonces

Hey everyone. How do we figure out the connection between the two nonces in a bitcoin transaction signature? Is there anyone who has some insights on this? Also, what formulas do you guys use to determine the K value?

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

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.

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?

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.

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

So how to find nonce leak?

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.

Hi iceland2k14, i find those points very very important but have a question regarding point 3. I was trying your scripts from https://github.com/iceland2k14/rsz and trying to understand the Math (in the read me) but that's not easy. my question, in point 3 you assume (just a luck) some combinations between k1 & k2 (which may or may not exist) and try to solve ... so which combinations are you using in the rsz_rdiff_scan.py script. Before i only knew about point 1 ..(i think that's when r1=r2) correct?   Regards, Baboshka

find - hard way, modify nonce with multiply to 2^362 if use r <= 2^254, result will be nonce with ff in  start. for find relationship, add 02 or 03 to two r, after subtract one publick key from another, brute forse result pubkey, result will be difference in nonces. ps some time need clean r from z and s component.

In an ECDSA signature, we can denote K as: K = ((H(m) + R * D) * S^-1) mod N Since we do not know D, we have no way infer any information about K. and vica versa.