Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 206. (Read 215272 times)

I'm okay with more false positives as it's easy to filter the found.txt file later on. But did it help with the speed at all?

Agreed! I did exactly this about a year ago.

The program still completes/computes the full rmd160, but then only checks for x characters against the bloom/file used.

I also did it with x points.

I can’t remember the length of rmd160 prefix but I do remember starting with 20 characters of x point and getting many false positives and slowly shifting the characters up to around 32; so roughly half of the x point, to limit the amount of false positives.

Bloom filter works exactly like this. It's a memory-time tradeoff. You can adjust the filter parameters so that it takes less memory, but in this case it will give more false positives.

I'm genuinely interested in knowing what would happen if we generate the hash160 then ignore the last 30 out of its 40 characters then load only the 10-digit prefix into the bloom filter to look for it against our target h160 prefix(es). Does this only mean less memory used by the blf and that's that?

Again, the codes already do this.

I know it will be too hard for you to look at VS code on GitHub, or you would have already done it.

Look at keyhunt Cuda. You actually provide it with a list of rmd160s, in binary format, sorted.

If you are merely talking a rmd160 prefix versus full rmd160, there would be no speed up. The full rmd160 is already generated from the public key.

The most time consuming part of address generation is the first step, the actual math part.

Why don't you then develop one yourself? Lol t's not even hard though.

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

VanitySearch checks the full address (i.e. performs full hashing) only if the given prefix matches, and before that it calculates and works with ripe160 only.
I didn't delve into the bitcrack algorithm much, but I know for sure that it decodes given addresses into ripe160.

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.

You know I was wondering, when I try to search for 7 char prefix by entering only 7 characters, and by searching for the full address I get the same speed and performance.

Unless programs such as vanity and bitcrack can magically turn 7 characters into a complete rmd160 hash and just search for the hash instead of address, then I can't see a reason as to why searching for full address and 7 char prefix would have the same speed.

According to you those tools decode the address we give them and then only search for the rmd160, decoding the prefix of an address gives no clue about the actual rmd160 hash of said address, therefore they all are hashing the rmd160 twice with sha256 algo in order to find the correct checksum, hence slowing down the process.

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

That's an interesting theory and probably useful with the current bruteforcing tools.
However, the creator of the puzzle already disclosed that there's no solution to the "puzzle" nor made the PrvKeys sequentially.

For reference, here's his only post in the forum (confirmed by most users): https://bitcointalksearch.org/topic/m.18765941
Here's my take on what he meant by "masked with zeroes": https://bitcointalksearch.org/topic/m.61997068

I answered Green  :D

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.

There's a prediction model based on statistics of previous puzzle keys. It is made by HomelessPhD and kinda sophisticated  The repository is on github if you wanna take a look.

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

I can agree with that LOL!

Its probably as good as anyone else's guess lol

if anyone wants to try it make a input.text file
I filled it with
e9ae4933d6
153869acc5b
2a221c58d8f
6bd3b27c591
e02b35a358f
122fca143c05
2ec18388d544
6cd610b53cba
ade6d7ce3b9b
174176b015f4d
22bd43c2e9354
75070a1a009d4
efae164cb9e3c
180788e47e326c
236fb6d5ad1f43
6abe1f9b67e114
9d18b63ac4ffdf
1eb25c90795d61c
2c675b852189a21
7496cbb87cab44f
fc07a1825367bbe
13c96a3742f64906
363d541eb611abee
7cce5efdaccf6808
f7051f27b09112d4
1a838b13505b26867

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

Yeah, 76 bit is about the max for a decent time run on a CPU; because of the limits on cores/threads.

I did try implementing a stride function on GPU but can’t figure out what it’s doing wrong.

So then I ran bitcrack with stride function but there are so many limitations. It’s a lot slower than other key cracking software, the code is all over the place, you can only run 1 GPU at a time, no networking feature to share key range, etc.

But I did manage to scan and find keys in a 56 bit range in 11 seconds (nothing great for such a small range) and 60 bit test yielded results between 1 min and 3 mins; depending on where the key lied in relation to the closest thread.