Reused Nonce r Between Different Private Keys – Possible MT19937 Issue

[peakyclin77]

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?

[nc50lc]

The addresses are mathematically related, and the total funds involved are around 4 BTC.

I'm just curious: please explain how the addresses are mathematically related.
Since if those are the common P2PKH addresses, those are just encoded "HASH160" of the public key.

BTW, there are a lot of old and new topics here that discussed unrelated transactions with matching R value.
Most of the legit ones are implementation bugs from old wallets or old versions of wallet that are still available today.
Check the advanced Forum Search function (/index.php?action=search) to check if the related addresses had already been discussed before.

[ABCbits]

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

Full disclosure of milksad vulnerability mention MT19937 used by older version of bx binary.

We follow the call path:
pseudo_random::fill(data_chunk& out) -> pseudo_random::next() -> pseudo_random::next(uint8_t begin, uint8_t end) -> std::mt19937& pseudo_random::get_twister()

Wait a moment. mt19937, twister - this uses the Mersenne Twister PRNG? 🤔
At this point, the first alarm bells are going off. Mersenne Twister is not a CSPRNG, so it shouldn’t be in any code path that generates secrets. One alarming property of the Mersenne Twister is that its internal state can be reversed by an attacker who knows a few hundred outputs, endangering the secrecy of the other outputs of the same stream that the attacker doesn’t know (in simplified terms).