Understanding GCD Bias on signature generation (Need Technical Expert Assistance

[Rapten]

Okay, how do I even begin, it all started about two months ago when I came across a crypto scam wallet that is connected to a pigbutchering scam that had hundreds of thousands of transactions and I thought wow that seems odd to me there has to be some sort of vulnerability in this wallet that could help rescue these victims from. So I start poking around and it appears that some of its earliest transactions exhibit GCD bias of about 39% back when the random generator for signature was using prng before RFC 6797 was implemented there is a window of about 3000 signatures in this wallet that are all bias'd however besides reuse and several failed lattice attempts later I've hit a brick wall on attempting to break the key for the wallet to try to release all the funds from all the people this wallet has scammed. Its automated runs batched transactions produces thousands of transactions daily and appears to have fixed its initial prng state which is why anyone that pulled up all the transactions for it and tried to build a lattice for the wallet would straight up fail it's been diluted from better rng as time has gone on. For grins I started poking around a few other wallets with a similar mo thousands or hundreds of transactions per day gcd bias in their implementation initially that smooths out over time. I would really love if anyone who understands this stuff and is interested and willing to help me recover the funds for this wallet. we are talking massive money in the neighborhood of hundreds of millions of dollars in these wallets that I truly would love to set back to their original owners. Anyway if anyone understands how the python scep256 libraries changed during 2022 to around July 2022 and has the technical expertise on how to crack this sort of implementation and wants a project I'm sure it would end up with a sizable reward I'm more than willing to share all the knowledge I have on the situation and would love to get an expert opinion on how this stuff works. I set up sage math and have fpylll installed along with all the other dependencies but just honestly don't have a complete grasp how to get this past the finish line. If anyone wants to help I'm sure if we crack this anything any of the victims get back would be a win for them.

[Roberto888]

You're dealing with a classic ECDSA nonce bias attack scenario. The key insight you're missing is that even with later signatures using better RNG, the initial biased signatures still create a solvable hidden number problem.

The attack works like this:
1. Collect all signatures from the biased period
2. Form lattice using the biased nonces (even partial bias helps)
3. Use lattice reduction (LLL) to recover private key

Your main issue is likely in lattice construction. Since the bias isn't present in later signatures, you need to focus only on the ~3000 biased signatures and build your lattice from those. Don't mix in the good RNG signatures.

The bias means: k = k_biased + small, where k_biased is predictable. This creates a solvable system.

If you want to share the transaction data, I can help construct the proper lattice. The money is definitely recoverable with the bias you described.

[Donneski]

From what you’re describing it does look like those early signatures probably came from a weak PRNG but a 30–40% bias alone usually isn’t enough to crack anything unless it stays consistent. Since the bias fades in later transactions that typically means the implementation improved which also explains why your lattice attempts hit a wall.

If the goal is helping the victims, it may not be realistic to assume the wallet is still vulnerable. Most successful key recoveries come from repeated or leaked nonces not general bias.

If you can share a small anonymized sample of the affected signatures I'm sure forum members especially the more technical legendaries would be able to tell quickly whether there’s anything actually exploitable.

[BattleDog]

The right way to approach this is to stop looking at "all transactions ever" and carve out the earliest clean window where you know the bad RNG was in use and is stationary. That might be a few hundred or a couple thousand sigs, not tens of thousands. Anything after the fix is just poison for your lattice.

On the practical side, if this really is tied to a pig-butchering operation with hundreds of millions flowing through, don't assume you're looking at a single hot wallet key that stayed unchanged for years. There are often multiple keys, scripts, services behind the scenes, and the funds you care about may have already been swept to harder targets long ago. Recovering one compromised key (if it's even possible) doesn't unwind the whole scam.

I'm not trying to pour cold water on the effort, if you've genuinely found a wallet implementation leaking k and it's still being used, that's a big deal. But the gap between "my GCD plot looks funky" and "we can reliably recover a private key" is huge, and you really want a couple of people who live and breathe lattice attacks to sanity-check this before you burn yourself out chasing ghosts.