Hello everyone,

I'm still working on solving a puzzle posted at https://bitcointalk.org/index.php?topic=5535021.0

Today, I'm focusing on a specific key that might help trivialize solving half of the puzzle.
This key's corresponding address is currently empty, and I've managed to collect a total of 5 valid ECDSA signatures related to it.

Here's the analysis — I'm particularly looking into whether the signatures reveal enough bias to attempt a lattice (LLL) attack using only 5 samples.

=== Fine-Grained Analysis of S Distribution ===

S in [1, n/4]: 4/5 → 80.00%
S in [1, n/8]: 3/5 → 60.00%
S in [1, n/16]: 1/5 → 20.00%
S in [1, n/32]: 1/5 → 20.00%
S in [1, n/64]: 0/5 → 0.00%
S in [1, n/128]: 0/5 → 0.00%

Result:
MAX BIAS: 4/5 signatures (80.00%) in [1, n/4]
→ Strong bias detected, likely due to a biased nonce k.
=== Exhaustive Bit Analysis of S ===

Total signatures: 5
Number of fixed bits (always 0 or 1): 16

Fixed bits:

    Bit 4: always 0

    Bit 8: always 1

    Bit 49: always 0

    Bit 50: always 0

    Bit 55: always 1

    Bit 69: always 0

    Bit 77: always 1

    Bit 93: always 0

    Bit 102: always 1

    Bit 103: always 1

    Bit 116: always 0

    Bit 146: always 0

    Bit 180: always 0

    Bit 183: always 0

    Bit 202: always 0

    Bit 255: always 0

Max block of consecutive fixed bits: 2 bits (starting at bit 49)
Low 8 bits of S: ['0x6e', '0x2a', '0x29', '0xe4', '0xcc']

Result:
MAX BIAS: 16 fixed bits; max block = 2 bits
→ Strong bias detected, possibly due to structural patterns in k

Can such a bias with only 5 signatures be sufficient to attempt an LLL attack?

Any thoughts or experiences would be greatly appreciated.
Thanks in advance!

here’s the latest news on the addresses I’m currently working on. I’m trying to determine the possible links between them. I don’t know any of the private keys (d1 to d7), nor k1, k2, or k3 — which I assume are large.

The most important goal here is to recover the private key d1, based on 9 signatures.

    d1 was signed using k1, k2, k3, or their opposites (-k1, -k2, -k3)

    d2 and d3 were signed with k1 or -k1

    d4 and d5 were signed with k2 or -k2

    d6 and d7 were signed with k3 or -k3

I'm looking to identify any exploitable link between these keys based on the above observations. Any idea, lead, or suggestion would be greatly appreciated.

Alright, thank you for your help. I managed to recover the DB key!

It turns out it was using the same K, but actually -K (so the same R, but with a negative K).

Now, I’ve identified other pairs of signatures (P2PKH addresses) that reuse the same R, but with different private keys, and I don’t know the values of the private keys or K in these cases.
These addresses seem to be related to the ones I just recovered, so likely generated in a similar context.

This time, I suspect that K is large.

So my question is: what would be the best approach to try sweeping these addresses and recovering the private keys?

Thanks in advance for your insights!

Hey everyone,

I came across a weird case while digging into some old addresses that reused the same nonce k (same R value in the signature), but across different private keys. Original thread here: https://bitcointalk.org/index.php?topic=5535021.0

The setup:
Three addresses (let’s call them A, B, and C) all sent funds to the same destination at the exact same second.

I have the private keys for A and C — not B.

Here’s what’s interesting:
The private keys of A and C have a GCD of 63.
I found other key pairs with GCDs of 18, 27, etc.

My question:
Could this GCD link help reduce entropy or even lead to the missing key (B)?

Thanks in advance!

Hi everyone,

I came across an interesting case involving the Bitcoin address "1LN4yp6rQALjwg53SKsi44teq1fp2v5wqR", which reused the same nonce k across two different transactions signed with the same private key.

Transaction 1: 65278a3cf6d4710bd5a556edeb6854e07de0324a5008569e33984da491df8c38

R = 00b42646001435ec60a40982735c4e73d31be13d0086be394eaf5ce10b0f38f689
S = 711a12a1a4db96159ec5760f2201beeb04043efc3d39e10ba17c9e66816ff9ad
Z = 91002245c37eba47e4f5764f0c4780b3cd9ba0f3ea709368cfd21717d82be496

Transaction 2: d87d1bc2d41ed867f0f4b7b7ee9915f09cb82477388e306acac8279146edacb8

R = 00b42646001435ec60a40982735c4e73d31be13d0086be394eaf5ce10b0f38f689
S = 5c55551c5a2348d32107f4c7174c9a90aa9621c927326f1e4294432192589f3d
Z = c47a2f11de95b92b65ee72082eda621ee681faf6e9abc64597325523f7d76202

r (same in both signatures): 00b42646001435ec60a40982735c4e73d31be13d0086be394eaf5ce10b0f38f689

It looks like RFC 6979 (the deterministic method for generating k) was not used in this case. This address is relatively well-known.

My question is:

Is it possible to determine how k was generated in this situation (e.g., weak PRNG, timestamp-based, or something else)? And could we potentially reproduce the same k with the right assumptions?

I’ve identified a case involving multiple Bitcoin P2PKH transactions where the same ECDSA nonce r is reused across different private keys. The addresses are mathematically related, and the total funds involved are around 4 BTC.

We know that when the same nonce k is reused across signatures with different keys, we get two equations with three unknowns (k, d1, d2). This usually isn’t enough to recover any private key.

However, I’ve been investigating how k might have been generated. My analysis points to a cloned virtual environment using MT19937 (Mersenne Twister), likely with the same seed reused to generate multiple private keys or nonces across transactions.

This could explain how the same r appears in signatures from different keys. As MT19937 is not suitable for cryptographic use, predictable nonces may be involved.

Questions:

Has anyone seen a similar case involving MT19937 and nonce/key reuse?

Any known attacks or tools to reverse-engineer k or the seed from reused r values?

Is there any way to exploit this pattern to recover private keys?

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.

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

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

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

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.

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?

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

amaclin1,

Thanks, I understand now. As mentioned earlier, all these addresses are compromised. For one address containing just over 2 BTC, there are 6 RSZ signatures in total. The second signature for this address shared the same rr with two other empty addresses, but it was the first to use this rr. In these 6 signatures, there are similar patterns, such as prefixes and fixed bits.

hello send me a message

amaclin1 Have you ever seen a similar exploitable case or an optimized brute-force method for this kind of situation?

amaclin1, these P2PKH addresses are compromised no matter what—around 4 BTC is at risk. The transactions accidentally reused the R value between addresses due to a biased PRNG. I’m looking for a brute-force method to recover the nonce or any other approach. I already have a private key that might be the master key for all these

In the scenario I mentioned earlier in the thread, where the same nonce 𝑟 is reused between different public keys, I have noticed that sometimes we observe two instances of reuse between two keys, or even three instances of reuse among three different keys. Given this situation, is there a way to recover the private keys associated with these compromised addresses through a nonce reuse attack or any other method?

Since we have two equations and three unknowns in this case, it seems like it might be possible to solve for the private keys. I am aware that there are approximately 4 BTC at stake in this situation.

Any insights on how to approach this attack, or if there are existing tools or techniques to recover the private keys, would be highly appreciated.

Thanks!

Hello,

I noticed that a P2PKH address d1 has reused the same nonce R = 532afmore twice, while the P2PKH address d2 has used R = 532afmore only once.

Since reusing the same R in two different ECDSA signatures allows private key extraction, is it possible to recover the private key of d2, given that it used R = 532afmore only once?

Thanks for your insights!

Hello everyone,

I made a discovery regarding some transactions from about 10 years ago. I will try to be as clear as possible about the situation.

A P2PKH address that I will name Ax:
1AxP2pkhFakeAddressExamplexxxx

Some P2PKH addresses that I will name:
A1 : 1A1P2pkhFakeAddressExample1
A2 : 1A2P2pkhFakeAddressExample2
A3 : 1A3P2pkhFakeAddressExample3
A4 : 1A4P2pkhFakeAddressExample4
A5 : 1A5P2pkhFakeAddressExample5
A6 : 1A6P2pkhFakeAddressExample6
A7 : 1A7P2pkhFakeAddressExample7
A8 : 1A8P2pkhFakeAddressExample8

Addresses A1, A2, A3, A4, A5, A6, A7, A8 sent approximately 100 BTC to Ax (1AxP2pkhFakeAddressExamplexxxx) through several transactions, for example:

Trx 1:
Ax : 1AxP2pkhFakeAddressExamplexxxx
A1 : 1A1P2pkhFakeAddressExample1
A2 : 1A2P2pkhFakeAddressExample2 >>> 1AxP2pkhFakeAddressExamplexxxx
A3 : 1A3P2pkhFakeAddressExample3
A4 : 1A4P2pkhFakeAddressExample4

Trx 2:
Ax : 1AxP2pkhFakeAddressExamplexxxx
A5 : 1A5P2pkhFakeAddressExample5
A6 : 1A6P2pkhFakeAddressExample6 >>> 1AxP2pkhFakeAddressExamplexxxx
A7 : 1A7P2pkhFakeAddressExample7
A8 : 1A8P2pkhFakeAddressExample8

Trx 3:
A1 : 1A1P2pkhFakeAddressExample1 >>> 1AxP2pkhFakeAddressExamplexxxx

Trx 4:
A2 : 1A2P2pkhFakeAddressExample2 >>> 1AxP2pkhFakeAddressExamplexxxx

Trx 5:
A3 : 1A3P2pkhFakeAddressExample3 >>> 1AxP2pkhFakeAddressExamplexxxx

Trx 6:
A4 : 1A4P2pkhFakeAddressExample4 >>> 1AxP2pkhFakeAddressExamplexxxx

Ax reused the same nonce r=00df8 in multiple signatures, which compromised the private key. Some addresses like A1, A2, and others also reused exactly the same nonce r as Ax (r=00df8). As a result, addresses A1, A2, A3 are compromised. However, I am struggling to recover them, although these addresses are empty. On the other hand, certain addresses like A3 and A4 reused the same nonce r=0074c when sending to Ax, without ever sharing the same nonce as Ax.
In addresses like A3 and A4, along with others, there is a total of about 4.50 BTC dormant.

Possible explanation: The nonces are generated by a random number generator whose state is stored in a virtual machine snapshot. After some time, the machine was restored to a previous snapshot and restarted. Then, after a few more days, the machine was restored to that same state, causing the nonces to repeat. The addresses are mathematically linked.

Question:
I would like to know, of course, if the addresses that reused nonces like A3 and A4 are compromised?