Re: == Bitcoin challenge transaction: ~1000 BTC total bounty to solvers! ==UPDATED==

I'm currently checking apps that I haven't checked before... and that's how I found PubHunt. I entered the 29 closest unresolved addresses without pubkey in the input... This way I achieve a scan of 6400Gkeys/s . What are the estimates that a pubkeys lookup for 29 addresses with this method and this program at this speed will yield the intended expectations more than a traditional key lookup? What are the real chances of success and effectiveness of this method?

Hi Zielar
Waouhh impressive this speed! If you could choose the beginning and end of the search range, you could find pubkey #66 between 2 and 4 months. On the other hand the search is carried out randomly it makes random hashes on the PK of #64 #66 #67 #68 #69 #71 and #72 it can be faster as well as much longer depending on luck. Too bad this program could be largely optimized like choosing the hash range #66 as well as the random or sequential mode with your speed you could come across #66 in 1 month or 2 depending on luck.

Edit
Looking more closely at the operation of this utility and your speed, the proba are these
in 10 days on all the beaches by inserting the 6 pubkeys (I calculated for the first 6 # not 29) you have a one in 148 chance of having one of the keys
in 20 days 1/74 1.35%
in 40 days 1/37 2.75%
in 80 days 1/18 5.5%
in 160 days 1/9 11%
in 320 days 1/4 25%
it remains arbitrary because luck can enormously speed up the process Grin

Is there any way to specify the bit range in this program ? I am newbie so any help would be appreciated
Thanks

I was trying to figure out a way to see if PubHunt even works. It is not easy to test on lower complexity keys. Would also be nice to see current key being worked on. So far I have.

https://github.com/Chail35/PubHuntRange

PubHunt.cpp
Line 330

printf("\r[%s] [GPU: %.2f MK/s] [T: %s (%d bit)] [F: %d] %02hhx %016llx %llu ",

%016llx should be the starting key. However it looks like this. and only upldates every few trillion keys.

[00:00:06] [GPU: 4316.00 MK/s] [T: 25,904,021,504 (35 bit)] [F: 0] a4 00007fffb46dd420 17179869184

Many thanks to Chail35 for recently updating this fork!

I am confused about the fork you provided the link for above. Confused as in, if it is working in a range, then there is no difference between this forked program and keyhunt-cuda.

The original pubhunt did not work in a range, it generated random public keys to try and link to a h160/address. Which, if you do the math, meant there could be close to 2^96 possibilities. But now, shrinking the range down to 66 bit or 67 bit, etc., makes that number more than likely just 1. 1 match compared to 2^96 possible matches is a big difference.