P2PKH Address Pairs with Reused Nonce k

[mcdouglasx]

there are similar patterns, such as prefixes and fixed bits.

If you know that k has a prefix or certain fixed bits, the complete value of k can be represented as:

(k= P+X), where X is the variable part (unknown bits). However, if these fixed bits are small, any Lattice attack will still remain unfeasible. This is why I mentioned that you need to compare all possible nonces from the signatures that can be recovered, with the hope of finding a clue, a pattern, a sequence related to something like Mersenne Twister, or differences between the r values.

[peakyclin77]

So, I have converted all the r values into binary and compared each one. Here are the results. These are the r values from the signatures of the address containing just over 2 BTC. Is the number of bits sufficient?


Comparison between r1 and r2:
Number of fixed (common) bits: 132 / 256
Ratio of fixed bits: 0.5156
--------------------------------------------------
Comparison between r1 and r3:
Number of fixed (common) bits: 125 / 256
Ratio of fixed bits: 0.4883
--------------------------------------------------
Comparison between r1 and r4:
Number of fixed (common) bits: 131 / 256
Ratio of fixed bits: 0.5117
--------------------------------------------------
Comparison between r1 and r5:
Number of fixed (common) bits: 132 / 256
Ratio of fixed bits: 0.5156
--------------------------------------------------
Comparison between r1 and r6:
Number of fixed (common) bits: 121 / 256
Ratio of fixed bits: 0.4727
--------------------------------------------------
Comparison between r1 and r7:
Number of fixed (common) bits: 136 / 256
Ratio of fixed bits: 0.5312
--------------------------------------------------
Comparison between r2 and r3:
Number of fixed (common) bits: 115 / 256
Ratio of fixed bits: 0.4492
--------------------------------------------------
Comparison between r2 and r4:
Number of fixed (common) bits: 125 / 256
Ratio of fixed bits: 0.4883
--------------------------------------------------
Comparison between r2 and r5:
Number of fixed (common) bits: 140 / 256
Ratio of fixed bits: 0.5469
--------------------------------------------------
Comparison between r2 and r6:
Number of fixed (common) bits: 125 / 256
Ratio of fixed bits: 0.4883
--------------------------------------------------
Comparison between r2 and r7:
Number of fixed (common) bits: 120 / 256
Ratio of fixed bits: 0.4688
--------------------------------------------------
Comparison between r3 and r4:
Number of fixed (common) bits: 134 / 256
Ratio of fixed bits: 0.5234
--------------------------------------------------
Comparison between r3 and r5:
Number of fixed (common) bits: 131 / 256
Ratio of fixed bits: 0.5117
--------------------------------------------------
Comparison between r3 and r6:
Number of fixed (common) bits: 122 / 256
Ratio of fixed bits: 0.4766
--------------------------------------------------
Comparison between r3 and r7:
Number of fixed (common) bits: 129 / 256
Ratio of fixed bits: 0.5039
--------------------------------------------------
Comparison between r4 and r5:
Number of fixed (common) bits: 133 / 256
Ratio of fixed bits: 0.5195
--------------------------------------------------
Comparison between r4 and r6:
Number of fixed (common) bits: 134 / 256
Ratio of fixed bits: 0.5234
--------------------------------------------------
Comparison between r4 and r7:
Number of fixed (common) bits: 137 / 256
Ratio of fixed bits: 0.5352
--------------------------------------------------
Comparison between r5 and r6:
Number of fixed (common) bits: 129 / 256
Ratio of fixed bits: 0.5039
--------------------------------------------------
Comparison between r5 and r7:
Number of fixed (common) bits: 132 / 256
Ratio of fixed bits: 0.5156
--------------------------------------------------
Comparison between r6 and r7:
Number of fixed (common) bits: 131 / 256
Ratio of fixed bits: 0.5117
--------------------------------------------------

[sdfasdf]

So, I have converted all the r values into binary and compared each one. Here are the results. These are the r values from the signatures of the address containing just over 2 BTC. Is the number of bits sufficient?


Comparison between r1 and r2:
Number of fixed (common) bits: 132 / 256
Ratio of fixed bits: 0.5156
--------------------------------------------------
Comparison between r1 and r3:
Number of fixed (common) bits: 125 / 256
Ratio of fixed bits: 0.4883
--------------------------------------------------
Comparison between r1 and r4:
Number of fixed (common) bits: 131 / 256
Ratio of fixed bits: 0.5117
--------------------------------------------------
Comparison between r1 and r5:
Number of fixed (common) bits: 132 / 256
Ratio of fixed bits: 0.5156
--------------------------------------------------
Comparison between r1 and r6:
Number of fixed (common) bits: 121 / 256
Ratio of fixed bits: 0.4727
--------------------------------------------------
Comparison between r1 and r7:
Number of fixed (common) bits: 136 / 256
Ratio of fixed bits: 0.5312
--------------------------------------------------
Comparison between r2 and r3:
Number of fixed (common) bits: 115 / 256
Ratio of fixed bits: 0.4492
--------------------------------------------------
Comparison between r2 and r4:
Number of fixed (common) bits: 125 / 256
Ratio of fixed bits: 0.4883
--------------------------------------------------
Comparison between r2 and r5:
Number of fixed (common) bits: 140 / 256
Ratio of fixed bits: 0.5469
--------------------------------------------------
Comparison between r2 and r6:
Number of fixed (common) bits: 125 / 256
Ratio of fixed bits: 0.4883
--------------------------------------------------
Comparison between r2 and r7:
Number of fixed (common) bits: 120 / 256
Ratio of fixed bits: 0.4688
--------------------------------------------------
Comparison between r3 and r4:
Number of fixed (common) bits: 134 / 256
Ratio of fixed bits: 0.5234
--------------------------------------------------
Comparison between r3 and r5:
Number of fixed (common) bits: 131 / 256
Ratio of fixed bits: 0.5117
--------------------------------------------------
Comparison between r3 and r6:
Number of fixed (common) bits: 122 / 256
Ratio of fixed bits: 0.4766
--------------------------------------------------
Comparison between r3 and r7:
Number of fixed (common) bits: 129 / 256
Ratio of fixed bits: 0.5039
--------------------------------------------------
Comparison between r4 and r5:
Number of fixed (common) bits: 133 / 256
Ratio of fixed bits: 0.5195
--------------------------------------------------
Comparison between r4 and r6:
Number of fixed (common) bits: 134 / 256
Ratio of fixed bits: 0.5234
--------------------------------------------------
Comparison between r4 and r7:
Number of fixed (common) bits: 137 / 256
Ratio of fixed bits: 0.5352
--------------------------------------------------
Comparison between r5 and r6:
Number of fixed (common) bits: 129 / 256
Ratio of fixed bits: 0.5039
--------------------------------------------------
Comparison between r5 and r7:
Number of fixed (common) bits: 132 / 256
Ratio of fixed bits: 0.5156
--------------------------------------------------
Comparison between r6 and r7:
Number of fixed (common) bits: 131 / 256
Ratio of fixed bits: 0.5117
--------------------------------------------------

You need to mention the address and transaction ID. I can provide a solution to your puzzle.

[amaclin1]

So, I have converted all the r values into binary and compared each one. Here are the results. These are the r values from the signatures of the address containing just over 2 BTC. Is the number of bits sufficient?

In my example above the 'Comparison between rx and ry' is 256/256
(of course, I can make any ratio below 256/256)
It is not possible to recover priv and k.

[sdfasdf]

So, I have converted all the r values into binary and compared each one. Here are the results. These are the r values from the signatures of the address containing just over 2 BTC. Is the number of bits sufficient?

In my example above the 'Comparison between rx and ry' is 256/256
(of course, I can make any ratio below 256/256)
It is not possible to recover priv and k.

You need to mention the address and transaction ID. send me DM
do you think the number of bits is sufficient?

[amaclin1]

You need to mention the address and transaction ID. send me DM

My set of {r,s,p,z} generated from external program, not from bitcoin blockchain data. This is more than enough to research.

do you think the number of bits is sufficient?

Number of bits in what? In 'r'?

https://mempool.space/tx/1618aa4dd0621d0b1842d38a01c3f3246898c28845ce49f973cb402e2f94553b
r=2,s=2 in all tx inputs
Go on! 

[peakyclin77]

Yes, the r value was reused. One of the compromised addresses is a P2PKH address holding a bit over 2 BTC, which ACCIDENTALLY shared the same R with two other addresses due to a cloned VM. This particular address has a total of 7 spends with a biased k.

I compared all r values above; for example, the comparison between r2 and r5:

    Number of fixed (frequent) bits: 140/256

    Fixed bits ratio: 0.5469

The 7 r values mentioned come from the same key. Here, r2 and r5 have 140 fixed bits in total.

Is there a way to brute-force the nonce?

[mcdouglasx]

Yes, the r value was reused. One of the compromised addresses is a P2PKH address holding a bit over 2 BTC, which ACCIDENTALLY shared the same R with two other addresses due to a cloned VM. This particular address has a total of 7 spends with a biased k.

I compared all r values above; for example, the comparison between r2 and r5:

    Number of fixed (frequent) bits: 140/256

    Fixed bits ratio: 0.5469

The 7 r values mentioned come from the same key. Here, r2 and r5 have 140 fixed bits in total.

Is there a way to brute-force the nonce?

It's difficult to help you from the perspective you're presenting (assumptions) because there is no generalized method that covers what you're asking. These attacks are constructed based on the data collected from the signatures, their patterns, their relationships... In other words, you won't find a direct answer to this because it requires specific information to build a system of equations that can solve it. Additionally, since this involves the blockchain, and without intending to discourage you, I believe that the potential vulnerabilities in transactions from 2015 back to its inception have already been exploited (the ones that could be). Therefore, I'm fairly certain that an expert has already examined your series of transactions, as the information is public and easy to find on the blockchain.

[peakyclin77]

Ok, so how can I retrieve the keys of addresses that share a nonce with a compromised address? I want to check if they follow a specific pattern to identify the ones that interest me in this case.

[mcdouglasx]

Ok, so how can I retrieve the keys of addresses that share a nonce with a compromised address? I want to check if they follow a specific pattern to identify the ones that interest me in this case.

What I would do is recover all the private keys (PKs) that signed with the same nonce. This way, using the PKs, you can derive the vulnerable nonces k from all the signatures that reused nonces. Once you have that, you compare their r values with those of the target signatures. If there is enough data, you can determine whether to proceed with a lattice attack, because I'm not sure if these fixed bits follow a specific order, so I don't know how viable it is.

The scripts to do this have already been shared with you in the thread.

[sdfasdf]

@peakyclin77
Can you share the transaction ID and P2PKH address pairs with the reused nonce k?

However, I have a few questions and points for clarification:

Nonce Recovery: Could you elaborate on the method for recovering the private keys from the signatures that reused nonces? Are there specific algorithms or techniques you recommend for this?
Lattice Attack Viability: You mentioned uncertainty about the order of the fixed bits and the viability of a lattice attack. Do you have any insights or resources that could help clarify this aspect?

[peakyclin77]

mcdouglasx, the code you provided does not allow me to recover D2 in this case. D2 used R = 729debfti99 first. Then, D1 used the same R = 729debfti99 twice.

I have the nonce k of D1 and its private key, but I can’t find D1.

[peakyclin77]

I would like to retrieve all the Pk in order to determine if an LLL attack could be effective for the concerned keys. In this specific case, how can I retrieve the Pk, please? I always manage to obtain Pk2, but not Pk1.

Trx 1
Private key 1
R= 1ecab5908a6a6e5715426b9a3a24f48fab3ace6ee410e297a792ecefd98e5b20

Trx 2 :
Private key 2
R= 1ecab5908a6a6e5715426b9a3a24f48fab3ace6ee410e297a792ecefd98e5b20

Trx 3 :
Private key 2
R= 1ecab5908a6a6e5715426b9a3a24f48fab3ace6ee410e297a792ecefd98e5b20

[sdfasdf]

I would like to retrieve all the Pk in order to determine if an LLL attack could be effective for the concerned keys. In this specific case, how can I retrieve the Pk, please? I always manage to obtain Pk2, but not Pk1.

Trx 1
Private key 1
R= 1ecab5908a6a6e5715426b9a3a24f48fab3ace6ee410e297a792ecefd98e5b20

Trx 2 :
Private key 2
R= 1ecab5908a6a6e5715426b9a3a24f48fab3ace6ee410e297a792ecefd98e5b20

Trx 3 :
Private key 2
R= 1ecab5908a6a6e5715426b9a3a24f48fab3ace6ee410e297a792ecefd98e5b20

Please reply to me. I am asking for the original transactions: Trx 1, Trx 2, and Trx 3. Why are you not sharing this?
If you provide it, I can help to solve this.
send me dm ?>

[peakyclin77]

Unfortunately, I won’t be sharing the transaction IDs or addresses publicly, for fear that someone might sweep the 4 BTC quickly. The address that reused the R value with the same key is publicly known. Do you have a solution to the mentioned issue?

[sdfasdf]

Unfortunately, I won’t be sharing the transaction IDs or addresses publicly, for fear that someone might sweep the 4 BTC quickly. The address that reused the R value with the same key is publicly known. Do you have a solution to the mentioned issue?

I understand your concerns about sharing transaction IDs or addresses. However, having the specific transaction ID would greatly help in analyzing the issue and providing a more accurate solution. If you feel comfortable sharing it privately, I assure you that it will be treated with the utmost confidentiality.

send me DM  transaction IDs or addresses

[COBRAS]

Unfortunately, I won’t be sharing the transaction IDs or addresses publicly, for fear that someone might sweep the 4 BTC quickly. The address that reused the R value with the same key is publicly known. Do you have a solution to the mentioned issue?

show bleared screen of 4 btc ?

I think this not true what adress had 4 btc

[peakyclin77]

Unfortunately, I won’t be sharing the transaction IDs or addresses publicly, for fear that someone might sweep the 4 BTC quickly. The address that reused the R value with the same key is publicly known. Do you have a solution to the mentioned issue?

show bleared screen of 4 btc ?

I think this not true what adress had 4 btc

it was mentioned that the 4 identified BTC are located in pairs of addresses that share the same nonce k in their signatures. Around 10 addresses are mathematically linked and belong to the same person who reused the same nonce k with the master key d(master). This master key also shared k with other addresses but not with the 10 addresses holding the BTC.

My new strategy is to determine how k was chosen for the master key d(master) in order to exploit this vulnerability.