No, but both Keyhunters can and in short nutshell, that is what Kangaroo does; think of all the points saved as an auto, continually growing, x point input file.

Superb result WanderingPhilospher especially only on CPU you get the result 4 times faster than with BSGSCuda and Kangaroo from JLP on my RTX 2070. I noticed that kangaroo was a little faster than BSGS on your 76 bit 18 min VS 20 min for 02BF6E9A6F10A15DC828E968FC96CF9BC80A98F42227CCBE2AC4947B637B3E8FB1
Out of curiosity I did a test with a key taken at random from the 80 bit range to compare BSGS again with kANGAROO then then if you want to test this same pubkey to display your result which should be 4 times faster so surely on the 20 MIN approximately just with CPU VS 1H20 on GPU with kangaroo and 5 Days for BSGSCuda
Kangaroo result 1h20 for this 80 bit 02b7e1f6b67c5c09ab3de91dcbe456716b98e7eb807f9c80160a5dea6e242e41bc
BSGSCuda result stopped (in 47 min 4410978597433994379265 key traveled) i.e. a little over 5 days on my RTX 2070 to get the key
On the large range Kangaroo remains for the moment still the fastest and most efficient in my opinion
Adapting KangaBGstrider V 1.01 on GPU could give the same result for this 80 bit in less than 1min or around 20 min on CPU, of course then everything also depends on the hardware used as well as the number deployed.
But I think that on a single GPU type RTX 2070 or 2080 the result could be given in 45s
Could you do a test on this pubkey 02b7e1f6b67c5c09ab3de91dcbe456716b98e7eb807f9c80160a5dea6e242e41bc to display your result when it is possible and if you want of course :-)


My results on the 76 bit with BSGS then Kangaroo





 80 bit pubkey 02b7e1f6b67c5c09ab3de91dcbe456716b98e7eb807f9c80160a5dea6e242e41bc

I wrote a python39 program to analyze patterns and trends and maybe an educated guess . no trends or patterns for 66  but likely output I will post the code on my github "unclevito2017" but here is the prediction for 66.
Next hexadecimal string: 2596c43425ad3bdfa
No pattern detected in input file


import re

def detect_pattern(nums):
    pattern = None
    trend = None
    count = 0
    diff_sum = 0
    for i in range(1, len(nums)):
        diff = int(nums, 16) - int(nums[i-1], 16)
        if pattern is None and i < len(nums) - 1 and nums[i+1:] and nums in nums[i+1:]:
            pattern = nums
        elif pattern is None and i < len(nums) - 2 and nums[i+1:] and nums + nums[i+1] in nums[i+2:]:
            pattern = nums + nums[i+1]
        elif trend is None and diff != 0:
            trend = diff
        elif diff == trend:
            count += 1
            diff_sum += diff
            if count >= 3:
                trend = diff_sum/ count
                break
        else:
            trend = None
            count = 0
    return pattern, trend

def predict_next(nums, pattern, trend):
    if pattern is not None:
        if pattern in nums:
            index = nums.index(pattern)
            next_num = nums[index + 1]
            is_pattern = True
        else:
            next_num = pattern
            is_pattern = False
    elif trend is not None:
        next_num = hex(int(nums[-1], 16) + trend)[2:]
        is_pattern = False
    else:
        next_num = max(nums, key=lambda x: nums.count(x))
        is_pattern = False
    return next_num, is_pattern

# read input file
with open('input.txt', 'r') as f:
    nums = re.findall('[0-9a-fA-F]+', f.read())

# detect pattern and trend
pattern, trend = detect_pattern(nums)

# predict next number
next_num, is_pattern = predict_next(nums, pattern, trend)

# write output to files
with open('output.txt', 'w') as f:
    if is_pattern:
        f.write(f"Next hexadecimal string in pattern: {next_num}\n")
    else:
        f.write(f"Next likely hexadecimal string: {next_num}\n")
with open('next.txt', 'w') as f:
    f.write(f"Next hexadecimal string: {next_num}\n")
    if is_pattern:
        f.write("Pattern detected in input file\n")
    else:
        f.write("No pattern detected in input file\n")

Its probably as good as anyone else's guess lol

unique though and the output will vary depending the number of inputs

Hello
I found this "puzzle" by a student who wondered if it is possible for the keys to be sequential, the answer to this is that it could be possible that a mathematical formula was used for this.

but it is also possible that he only did this:

n=1,256
r(2^n-1))

and then manually modify the values "randomly", It is most likely that he did so.

In short, I would have to investigate with more time, honestly I do not have the computational power to use brute force, but I can give you some statistical advice on this.

1- brute force with large numbers is always better randomly.
I will use the Monty Hall paradox as an example.

Suppose you're on a game show, and you're given the choice of three doors: Behind one door is a car; behind the others, goats. You pick a door, say No. 1, and the host, who knows what's behind the doors, opens another door, say No. 3, which has a goat. He then says to you, "Do you want to pick door No. 2?" Is it to your advantage to switch your choice?



At first the contestant has 1/3 chances, then when the host opens a door and gives you the option to change at first glance it seems that if you would have the same probability but no.

The car has a 1/3 chance of being behind the door chosen by the player. The other door have a probability of 2/3 and not 50%.

This is the reason why at this point in the "puzzle" a random search is always better than staying in a large range.

2- Is human randomness really random?

playing with some statistical algorithms I made calculations that are close to the range where there is a greater probability that the private keys are found.

Pn-                 range                                  found
65-     30580000000000000000         30568377312064202855
66-     61230000000000000000
67-     137500000000000000000
68-     266900000000000000000     
68-     459400000000000000000
69-     520700000000000000000
70-     978700000000000000000        970436974005023690481

Given that the range of the puzzles 65 and 70 of the formula that I use are close to reality, by statistics the ranges 66, 67, 68 and 69 exist the probability of being close to the real result.

if the puzzle creator made manual changes pretending randomness or disassociating from 2^n-1 , he fail because humans are bad at it.
we always tend to repeat sequences unconsciously by association.

exercise:

If I ask you to read 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 and quickly I ask you to say a color without meditating or thinking.
The most likely thing is that you chose the color: "answer at the end of the comment" (don't cheat, just say the numbers and say the first color you think of quickly).

my opinion

I don't know what is the reason for this, it's my first approach to bitcoin, but if the creator is rich enough to do it because I don't just take addresses like mine ( 1HUGxcudaxCdufCaYHRoNadeCa73i3hB2r) randomly and send money?
Does he try to test if bitcoin can be hacked? Does he want to encourage the creation of brute force tools?

Personally, I think it would be more likely to find a back door to the elliptic curve used by satoshi than to brute force 256.

In any case, if I were to do this, I wouldn't do it because my resources are basic.

I would use random numbers in a range


I would search for known public keys to maximize the performance of the code by skipping various processes that slow down the search.


I don't know if I'm wrong because this is a new world for me, if I am, please correct me.

sorry for my English.


answer: RED.

That's exactly how i do my pvt key search. Random is the name of the game when it comes to big numbers.

I'm surprised that although you're new to this, most of what you suggested was spot on. In fact, almost summed up the entire experience of this thread. Even the math algorithm part was once a thing to discuss in the early days of this puzzle

VS and KH def convert addresses to rmd160, not 100% sure about bitcrack. I also stated, "believe it converts the partial strings to 160"; you can check the code as well as I can.
Speed is the same unless you add a wildcard, then the speed drops tremendously.
The point is/was, you said, "Searching only for the public key, saves us a sha256 and rmd160 to skip." and I am saying that programs already do that, and some programs search for the rmd160 of an address, if rmd160 matches, the program checks and verifies by completing the complete address generation. So the speed up in programs, whether searching for rmd160 or xpoint, have been out for years.

I have a serious question, why can't we determine the range of a given private key by looking at the derived public key? Why is it so hard? I mean we practically know the range of all private keys and their public keys, I haven't figured it out yet as to why we can't easily map public keys to private keys, it's not magic but only math, even if it was magic we could nullify it. But since it's mathematics I would say all the answers are in "Permutation" equation, other than that there is no mathematic solution. So chop chop dear developers, get to work, we've got mouths to feed.🤣

---

You were actually right about this, I was assuming you were talking about searching for prefix before the hash operation completes, lol. But indeed it would be the fastest method to search for rmd160 prefix because it saves us a double sha256 hash.😉
And don't listen to some developers claiming their tools already do that, because they don't, otherwise why there is no option to set our desired rmd160 prefix? Because they all generate addresses from scratch and either check for a whole address match or for an address prefix, slowing down the process, I think we need some professional devs, these devs are rookies.🙃