Your Q that you have just linked to says this:


Emphasis on "in 256 range"

This is what I reverse-engineered for someone who thought they can reduce 120-bit keys a N number of smaller keys, where N is a tiny number like 260: https://gist.github.com/ZenulAbidin/e8687d9e16189c99d192e97d37e71dbe

As you can see, this exactly reproduces the results of the post I quoted.

Start with this public key 03bb2228d3ea32cb3c1eb160cc824a4ba8115f9a7f415d18ddcaac8193defc2c47

Divide it into 32 "zones", where the first zone is from f7fffffffffffffffffffffffffffffec4d965ff79ce5b39e1d3cb9869b48f37 to effffffffffffffffffffffffffffffecf03ef184454163803d538a40332dd2d (this script spits it into two ranges so that you can actually load this into programs).

Now you see the problem with this?

The generated range is already much bigger than the input range. (same for the other 31 zones - which all match your test output BTW)

A script that reduces keys is supposed to make the range smaller, currently, the only known script that does this is the one by iceland.

And it does that well (at the expense of making an unmanageable amount of keys). But you see, the number of keys you get from this can be drastically reduced not by splitting them up into "zones", but by using statistical analysis to see what bit patterns in OpenSSL private keys are more likely to appear in.

Because let's face it, the puzzle creator would've found it convenient to create hex private keys only from OpenSSL command line.

Again, the problem with your method is that it makes the range bigger than what we started with in the first place.

So please make sure methods you make actually reduce the range before bragging about them to the whole thread.