congratulations to the winner!
so, now 6.7 at fire.

this is true if you go through all the values ​​without taking into account entropy.

Of course, if you try to generate a random number of 10 bits a billion times, you can get the number 0. But if you try to generate a random number of 66 bits, it becomes impossible to get the number 0. In this way, you need to ignore values ​​that with the maximum probability could not be a private key.

I remember there was information about how the keys were generated.
If anyone remembers where it is in the topics, please write link here.
It is important to understand whether a 256-bit key was generated and “cut off”, or whether private keys of the required bit size were initially generated for each address.
This is important for estimating entropy.

NO. excusema

No, i mean I can reduce a generator range to skip not random values, so time to bruteforce reduced too.

For example, 23 bit key to test (python 3.11 + ice_secp256k1.dll).
with secret algo:
GOT: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rVkthFNsQ6i7
10.363348245620728 s

with usual range (2^22 ... 2^23-1)
GOT: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rVkthFNsQ6i7
16.832353353500366 s

with big values, like 66 bit, a lot of values just skiped as NOT random binary values, because cant be randomly generated by author (by wallet software).
for example, first value for 66-bit range is 100000100100100101010011001011000111000111001011000111000111001011, all values less is fail.
this value give generator as first value applyed with random's rules

anyway, pure python not a good instrument to get result. wanna use numba cuda.jit, but still learning how to.

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)

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

found a way to reduce 1/6 total range.
python proto give a nice result for all known PK.

hope CUDA version will be a nice with 66..70 profit.

good luck!

no, i search not a weakness.
each generator produce different randoms.
for example, python's randint create 256 bit with about 50/50 +/-10% zeros and ones.
but mt19937_64 in cpp produce only 32 bit, i generate pair (32+32=64) to test and got ~70/30% zeros and ones.
at 2013 bitcoin core used openssl to generate random keys. question is author are used this openssl generator or something else.
if yes, openssl compile different code for win, mac and *nix. compile flags also give different result.
if get statistic for exactly used generator, so possible make a faster bruteforcer to skip values wich have low score and probably cant be generated at 2013.

i know. i wanna know a env where this process was doing.

is OP still here?
can you explain your env used to create tx? win, mac, nix, python, btc core, other wallet? what a flags was used to compile openssl-1.0.1c?

is OP still here?
can you explain your env used to create tx? win, mac, nix, python, btc core, other wallet? what a flags was used to compile openssl-1.0.1c?

use Electrum and disable Replace-By-Fee to avoid double spending.

D-9
Thank you!

yobit, +1598% last day.

seems "The Puzzle Level 6" is unsolvable.
needs to check 121 645 100 408 832 000 combinations to get a 11$..
letter matrix have 25 words, but needed only 24.
18 words have unknown order - its very hard to bruteforce right order, but we have 19 finded words so problem bigger.

Still can't understand why she's comb have 21 teeth... not 22 nor 20.
Solution is not an answer for puzzle question. Solution describes a method to choose a teeth count, but not why is 21.

just find at forum all addresses/transaction was posted before by topicstarter.
address got from this post: https://bitcointalk.org/index.php?topic=5157255.msg51593793#msg51593793

this address?
https://www.blockchain.com/btc/address/3FwZMvREgn7fNtpFSxFEQQPdjw14WnAGon