Hi, who are you talking to, do you need someone help you cross the street? 😂

---

Since you cared enough to share your achievement verbally, could you be kind and tell us how did you managed  to reduce the range for an unknown key? You know sharing is caring right? But if you found a way to do range reduction for public keys, let us know about it, we might find some useful hints.😉

it's wrong.
for example 7-bit key can be found at 4 step (direct search from 2^6 to (2^7)-1 will find only at step 12, reduce 3 times).
1001001 1
1001010 2
1001011 3
1001100 4
result: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7hDgvu64y

17-bit at 17318 (direct at 30287 step, reduce ~2 times)
10111011001001111 17318
result: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFiHkRsp99uC

22-bit (direct 910351)
1011011110010000001111 607024
result: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rP9Ja2dhtxoh

and so on... tested with known PK.
but still at researching.
8-bit key skiped by this method, therefore, unfortunately, there is a possibility of missing the desired value.

i was wrong about 1/6 (error with calculation was), anyway reduce are possible, but with chance to skip needed value =(
and we must take into account that by skipping some values ​​when generating numbers, we save time on generating the address and checking it with the required one (speedup).

many test was. real steps to find was different.
22-bit at this test is:
1011011110010000001111 777854
but anyway its better vs range(2**21, 2**22-1)

Hmm why is the keyspace shown different here on the first site, this site https://privatekeys.pw/puzzles/bitcoin-puzzle-tx and this site https://privatekeyfinder.io/bitcoin-puzzle/.

  end will be, the puzzles are in the wrong keyspace, thats why nobody can find anything. Look at 66 for example, different keyranges.

Does anyone have concerns about the advancement of machine learning algorithms becoming increasingly capable of breaking complex encryption methods, such as secp256k1 and others?

how much time and resource to find a public key in range 40000000000000000000000000000...7ffffffffffffffffffffffffffff  115 puzzle with kangaroo

The best thing to do is to test your grid size and run through a small range, something like a 2^40 range. See if the grid size finds the key or not.

I use a similiar version of KeyHunt Cuda Rotor and haven't missed a key with a large grid size. But seriously, run a simple test to know for sure with your card and setup.

I would run a few tests. Put some keys at the beginning of range, the middle and the end. I've used some large grid sizes with no issues.

If you are using the rekey option, you will get fluctuation in your speed no matter the grid size; as it spins up to rekey and then picks back up.

You might be interested to read and learn more about grid sizes, there are more stats which you could find by visiting this nvidia page  there are technical stats on what is the acceptable grid size for different applications. You can't simply use any arbitrary grid size.

Yeah, I was testing different grids for my card the other day, within the reasonable bounds, keeping it a small multiple of the original grid.

After a while I decided to play with it a bit and increased the grid by larger factors, thus arriving at numbers like 18000 and 32000. They are not arbitrary.

I thought the program wouldn't even initiate. For my surprise not only it ran but it had increased speeds. Then it came to mind that it was probably jumping over a bunch of keys.  

It was too good to be true. I was getting a constant 5GK/s with sudden peaks to 9GK/s every few seconds running sequential X-Point mode with a grid-size like --gpux 36000x512 against #130.

Raise it much further than that and the speed will keep dropping to 0.00 MK/s for a few seconds during the entire search.

Anyways, if going for random mode I guess this issue could be overlooked? One can have more threads thus searching faster, the trade-off being skipping some keys...

About this other flaw [in a scenario where the grid-size is not causing it to skip keys] could I avoid it by updating the lower range in my .bat file to be the last key shown in the counter before terminating the session, instead of using continue.bat?

Thanks!