Quote from: WanderingPhilospher on May 05, 2024, 03:16:44 AM

Quote from: MrlostinBTC on May 04, 2024, 11:56:02 PM

Quote from: faiyaz_crysp on April 30, 2024, 08:00:14 PM

Quote from: Lolo54 on May 02, 2023, 11:51:59 AM

Quote from: zielar on May 02, 2023, 05:35:37 AM

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

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.

Hi,
I couldn't find the option to open an issue, so commented here instead.
In your usage example you used wrong start range and end range , seems its missing 1 digits.
KEY RANGE : 0x2000000000000000 - 0x3fffffffffffffff

If i enter the correct start range for the 66 puzzle address -sr 20000000000000000 -er 3ffffffffffffffff the program shows KEY RANGE : 0xffffffffffffffff - 0xffffffffffffffff
even if i change the -sr and -er to a custom short range i.e -sr 215fffffffffffff -er 215fffffffffffff it seems to show the same status on key range as KEY RANGE : 0xffffffffffffffff - 0xffffffffffffffff
can you have a look ? also is it possible to update the code so it shows the status of the current keys it's working on ?

https://snipboard.io/lpYitb.jpg