Hello everyone,

Here, the k values seem predictable and deterministic.

R1 = 0x5660647957179a737ee9f43d69ea7923ed179680acaea311986ba7bde67dd321
R2 = 0x566064795718a8c41789a5e3947f17cb2932dca737037bce9b49c7a75f606ce1

Relative Distance Ratio (Distance / n):
Fraction: 0.000000000000003751

Hello, please help me, here are the new data regarding my puzzle.
I was able to detect patterns in 2 clear models including 28 nonces. Two sets of 14 nonces were used in the same environment as the sought-after k values to complete my puzzle:

1st sample including 14 nonces
   •   Entropy per byte: 4.9375 bits
   •   Total entropy: 158 bits
   •   Weak byte positions: [2, 8, 12, 18, 19, 20, 27]

2nd sample including 14 nonces
   •   Entropy per byte: 4.8750 bits
   •   Total entropy: 156 bits
   •   Weak byte positions: [10, 12, 16, 17, 24, 26, 28]

I assume here that the sought-after keys, having reused the same k across different keys, used exactly the same structure to generate these signatures.

What would be the way to solve this, if possible, without relying on the network? Thank you for your answers.

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, meaning they are both exactly divisible by 63 — i.e.,
dA = a × 63
dC = b × 63

I’ve also found other key pairs with GCDs of 18, 27, etc. This suggests some kind of structure or weakness in how these keys were generated.

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

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!