There's the math comes again,

66 Bit puzzle  


the total number of keys in this range can be calculated by taking 16 to the power of 17 (i.e., 16^17), which is equal to 295,147,905,179,352,825,856.

So, there are a total of 295,147,905,179,352,825,856 keys in the given range.

If you have a speed of 343 million keys per second (Mkeys/s), the result's,

Total number of keys = 295,147,905,179,352,825,856
Time = Total number of keys / Speed

Substituting the values, we get:

Time = 295,147,905,179,352,825,856 / 343,000,000
Time = 859,488,566,568 seconds

Therefore, it would take approximately 859,488,566,568 seconds (or about 27,247 years) to generate all the possible keys in the given range at a speed of 343 million keys per second. This is a very long time and may not be practically feasible.

what if i have 5000 mkeys to scan those number of key ?
it would take approximately 59,029,581,036 seconds (or about 1,872 years) to generate all the possible keys in the given range at a speed of 5000 million keys per second, still lame haha  

---

and there's other scenario to win the ticket haha

For a 66-bit puzzle, the key range would be from 0 to 2^66 - 1, which is:

0 to 7,922,816,251,426,433

The number of keys in this range is:

2^66 = 73,786,976,294,838,206,464

At a scanning speed of 343 Mkey/s, the time it would take to scan this entire range would be:

Time = Number of Keys / Keys per Second

Time = (2^66) / 343000000 = 215625224 seconds
= 3593754 minutes
= 59896 hours
= 2495 days
≈ 6.84 years

So, it would take approximately 6.84 years to scan the entire key range of a 66-bit puzzle at the given scanning speed.

If we were to randomly hit the private key in the middle of the range, then we would only need to scan half of the key range, which is:

2^65 = 36,893,488,147,419,103,232

Using the same formula as above, the time it would take to scan half of the key range would be:

Time = (2^65) / 343000000 = 107812612 seconds
= 1796877 minutes
= 29948 hours
= 1248 days
≈ 3.42 years

So, if we randomly hit the private key in the middle of the key range, it would take approximately 3.42 years to scan half of the key range at the given speed of 343 Mkey/s.


btw, my close friend is neat, he's building something on ASICs L3+ to give a proof to scan the puzzle for mean time haha.
let's see..

Everyone thinks he will be the lucky one and prefers to avoid having to share the X10 is made to encourage people to pool their power to demonstrate that even with a collective effort the 66 67 68 and 69 will be difficult to obtain otherwise it won't find away
Also give a good boost to this puzzle which is now 8 years old

What domain do you own/have?

I had a pool running over 2 years ago, for #64. People say they will run their GPUs but we only had around 2-4 people running consistently.

What would be nice is to know everyone’s fire power, and then decide what tools to use, and best setup. But most get excited in the beginning and then fizzle out a week or so later when the key hasn’t been found lol.

that makes things a bit easier. let me do some more digging and ask some question to some fellow resources. i could possibly pay someone to sett it up if you have all that ready atm.

Personally id love to but i am no good at coding gamming and shipping packs is my strongsuit. if you or anyone you know can make such website i would know how to set escrows up and or someone should contact the mod of this group or one of the others as a "middle man" like i said before though id be willing to run my pc 24\7 till it caught fire or we cracked  the puzzle
also idk if you guys know either  theres multipule other groups like us. kagroos group and 1000 btc puzzle group aloty of hidden info and new people in those too id take a lookk at some the links can be found on page 1 think or whatever the main page is explaining it all.

   say you even get to 90 bits with a collabed group with the m oney you make options are endless after tbh

i litterly just copied and pasted a link from github also . i have no idea if it contains some type of malware use at your own risk as i said im a script kiddie to invested to give  up now. my last question is why has noone made a website holding a escrow account that the btc would go to if cracked and split evenly appon such individuals when foudnd. also has anyone thought of good old Darkweb?? maybe paying a person to hack it for you or use their computing skills to brute force it for a lump sum if not half of whats  recvovered

00000000000000000000000000000000000000000000000363d541eb611abee
Start key 0000000000000000000000000000000000000000000000002000000000000000
Stop key 0000000000000000000000000000000000000000000000003fffffffffffffff
2000000000000000...3fffffffffffffff (261...262)




EX 0000000000000000000000000000000000000000000000349b84b6431a6c4ef1
Start key 0000000000000000000000000000000000000000000000200000000000000000
Stop key 00000000000000000000000000000000000000000000003fffffffffffffffff




through the searching ive done this could mean nothing but  i think #66 has to start= with 35

theory:  #62 has a start stop with 2 and 3  #70 has a start stop of 2 and 3. both a little apart in think the middle filling one is #66. starting at 35.................

The value of unsolving puzzles goes up 10X today😇

Hi, I'm here again with more questions, appreciate the answer. Isn't it faster to search for RIPEMD-160 instead of address? Or the check encoding of hash 160 to address doesn't require any computation

I must admit i gave up seeking solutions for those puzzles. It consumes to much time and gives nothing.

I've tried 125 with BSGS and Kangaroo  ... i've tried 66 in random mode ... and my conclusions is: These numbers are just too big for seeking with home computer.

Even the topic name is misleading here - These are not PUZZLES ... there is no puzzle , no pattern , nothing. Just massive random numbers. With current hardware possibilities it could be solved but we need massive amonut of hardware to do it in a reasonable time.

It should be called something like "Computational Power Competition" or "Bitcoin Benchmark" not a "puzzle".

The only thing that can be solved by an average person are puzzles about maybe 90 - 100 bits but only in case the creator will reveal the public keys. But then solving puzzle 66 is a matter of few minutes and only competition is who will notice first that the public key is available ( and I doubt that was the goal of creator of all this thing).

When you realize with how big numbers we deal here and what is the speed of our machines the only solution is to give up.

Of course one would treat this as a lottery but considering the power consumption and ultra low chances to win  a (let's be honest) not that big reward (its significant amount but not a life changer) i doubt it's worth it...

Anyway it was useful experience from educational point of view.

I never found the BSGS-CUDA running on linux/debian, still use the Windows version, There's the github you can download the BSGS-CUDA windows and already compiled.
you just need extract the zip, and put the exe on the same file.

test your luck here, it's safe no random malware.

https://github.com/Etayson/BSGS-cuda/releases/tag/v1.7.3


I try to scan the #65 Puzzle with BSGS-CUDA, using GTX1650Ti

results,

START RANGE= 0000000000000000000000000000000000000000000000000000000037d72a06
  END RANGE= 000000000000000000000000000000000000000000000000000000003fffffff
WIDTH RANGE= 000000000000000000000000000000000000000000000000000000000828d5f9
SUBpoint= (2bdeb0a84d7f1cf940ab6a47875939fcfb52e07e8598de29978f67b3979dc202, a0c47daf4ac0e02a1f3754e25bcd471d9a599db7432d80794df604814fcf75fd)
Save work every 180 seconds

FINDpubkey: 030d282cf2ff536d2c42f105d0b8588821a915dc3f9a05bd98bb23af67a2e92a5b
Cnt:1 [1][ 0 ] = 0 MKeys/s x2^27=2^27.00 t:00:00:00
KEY[1]: 0x000000000000000000000000000000000000000000000000000000003d94cd64
   Pub: 030d282cf2ff536d2c42f105d0b8588821a915dc3f9a05bd98bb23af67a2e92a5b
Working time 00:00:00s
Total time 00:00:05s

GPU#0 job finished
GPU#0 thread finished
cuda finished ok

only 5 seconds.

IMO imagine the puzzle maker show pubkey the #66 Puzzle, maybe it's take the same time like 10-20 seconds haha.

I knew because it's difficult by times to search too, there's no magic tools to solve the puzzle by day,month, years for possible.
last time i scan the 125# puzzle with my 1650Ti, it takes like 800-900 years, im new in this puzzle and learn from people who's tryin to figure the pattern to breach the puzzle.

FUN FACT is you need like 1000-2000 GPU units for breach the #66 with kangaroo, to short the time like 1-2 years.

regards,

So the point is we cannot do anything to solve the 66, because we need public key, we cannot seek the public key because the address never spent any ammount thoo 

I do RMD, and PUBRMD, for like 1 years and nothing to found.



#120 never given the hex key too 

Until we don't have the capability to count in a sequence, we will have to estimate some parts randomly and complete the remaining parts by counting them in the sequence. Besides this, we do not have any other alternative method available.

Therefore, I am dividing Puzzle 66 into two parts and as we know it will start with 2 or 3, I have assumed it will start with 3. Then, I am incrementing the 1 in the 8 hex ("30000000") up to ("3fffffff"). In this process, I am comparing the address of Puzzle 66 with the addresses obtained from incrementing the 8 hex. If the 8 or more character of Puzzle 66's address match with the address obtained from incrementing the 8 hex, I took that 8 hex as first part of 17 hex of P66 and counting the remaining 9 hex using VanBitCracken. This process gave me approximately 427 ranges, and it took me about 70 seconds to complete one range. Thus, it took me about 8 hours to complete 427 ranges. I believe that using some logical approach for counting, instead of generating completely random hex, may lead to a solution. I am aware that this is also a random method, but with a little logic. I know there is unequivocally no shortcut to solve this puzzle. However, unless I have the capacity to count in a sequence, I will have to resort to some shortcut method.

@zahid888: can you explain please what you're trying to explain or show? as far as I know it does not matter if only certain substrings of the searched bitcoin address match or not, that does not help in finding the right key for #66. As we all know, the hash value changes completely if you change only a single character of the initial value. So I don't understand how your output from VanBitkracken is supposed to help.

I was thinking about the same. Why scanning ranges like 2FFFFFFFFxxxxxxxx etc...  I can bet the private key for 66 puzzle dont have more than two same digits one by one.

But then i realized it has only meaning in case of bruteforcing one by one. But when we are using random mode chance that we check whole ranges of keys with many the same digits are so small that it has no meaning.

Correct me if im wrong.  The best method is massive power and random seeking.

Generating the ranges to then feed them to a program is a waste of time.

There are only 16 total characters. 10 digits and 6 alphanumeric.

You would create an ungodly amount of small ranges.

Example:
1111a-1111f would be one single range.
Ffff0-ffff9 would be a single range.

The program would spend more time starting and stopping than actually getting through ranges.

If it’s hard coded in a program, maybe it would save some time, I’m just not sure how much.

Edit:

Let’s deal with #66
First 10 keys would be skipped
The next 6 would be checked
The next 10 skipped, the next 6 checked
Rinse n repeat

While a program is stopping n restarting to the next range; the same program would have checked millions of keys within that same time. A single core on keyhunt Cuda can do 3-4 million keys per second; it would take at least 2-3 seconds for a program to receive the end of range, shut down, and start the next range. I think if you are generating ranges to feed to a program, it will be much slower.

I think rotor Cuda dev had some program that skipped triples, such as 111 or fff, etc. I think it was for mini keys or WIF, I’m not 100 % sure. But he had the skips programmed into the program.

If it could be done with a key cracking program, I’d be interested in the speed comparisons.

Finally someone understands me! Now about how we could skip searching such keys? Isn't it obvious? We need to invent our own hexadecimal only key range. Honestly when I theorize such ideas, I don't really formulate them, because doing that takes a lot of time, I'd just introduce them to see if anyone is already versed in that area to see if they can formulate it faster.