And don't listen to some developers claiming their tools already do that, because they don't, I think we need some professional devs, these devs are rookies.🙃
Why don't you then develop one yourself? Lol t's not even hard though.
Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 229. (Read 229433 times)
And don't listen to some developers claiming their tools already do that, because they don't, I think we need some professional devs, these devs are rookies.🙃
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.🙃
And even better, what if we can apply the prefix concept on hash160 too. Instead of looking for address prefix, we look for hash160 prefix. Even more speed. In fact, this would be the fastest way ever.
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.🙃
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.
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.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.
I didn't delve into the bitcrack algorithm much, but I know for sure that it decodes given addresses into ripe160.
And even better, what if we can apply the prefix concept on hash160 too. Instead of looking for address prefix, we look for hash160 prefix. Even more speed. In fact, this would be the fastest way ever.
Won't work, rmd160 has 40 characters and by searching for their prefix, should we stop hashing half way? Meaning converting sha256 hash of public key into rmd160 but only looking for a specific prefix, either we generate the whole hash and compare with our target or we can't generate just a prefix to compare because it would break the function and we wouldn't know the result.About brute force tools, bitcrack, vanity etc they all convert rmd160 to address, otherwise why would they accept an address as an input to check against?
I also believe it converts the partial strings to 160 as well; I’d have to recheck on that but I’m pretty sure it does.
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.
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.
And even better, what if we can apply the prefix concept on hash160 too. Instead of looking for address prefix, we look for hash160 prefix. Even more speed. In fact, this would be the fastest way ever.
Won't work, rmd160 has 40 characters and by searching for their prefix, should we stop hashing half way? Meaning converting sha256 hash of public key into rmd160 but only looking for a specific prefix, either we generate the whole hash and compare with our target or we can't generate just a prefix to compare because it would break the function and we wouldn't know the result.About brute force tools, bitcrack, vanity etc they all convert rmd160 to address, otherwise why would they accept an address as an input to check against?
I also believe it converts the partial strings to 160 as well; I’d have to recheck on that but I’m pretty sure it does.
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.
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 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.
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
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.
-snip-
That's an interesting theory and probably useful with the current bruteforcing tools.-snip-
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
answer: RED.
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.
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.
Its probably as good as anyone else's guess lol 
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
Its probably as good as anyone else's guess lol
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 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")
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")
Quote
Could you do a test on this pubkey 02b7e1f6b67c5c09ab3de91dcbe456716b98e7eb807f9c80160a5dea6e242e41bc to display your result when it is possible and if you want of course :-)
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.
Doing some testing on 76 bit...
Code:
KangaBGStrider v1.01
Range Start :0 (0 bit)
Range End :FFFFFFFFFFFFFFFFFFF (76 bit)
Public Key(s) :1
Creating Stride Table...
CPU thread(s) : 8
Stride Table Complete: Max Stride: 2^36
Stride Avg Distance: 2^34.09
Number of Striders: 2^13.00
Suggested DP: 22
Expected operations: 2^41.39
Simulated DP size: 32 [0x00000000FFFFFFFF]
[31.88 MS/s][GPU 0.00 MS/s][Total Collision Checks 2^32.97][05:04 (Avg 1.0d)]
Key# 0 [1S]Pub: 0x02BF6E9A6F10A15DC828E968FC96CF9BC80A98F42227CCBE2AC4947B637B3E8FB1
Priv: 0x865CE114686A1301A4C
Done: Total time 05:05
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
Code:
C:\Users\Laurent>C:\Users\Laurent\Documents\Bitcoin\BSGSgpu.exe -t 512 -b 72 -p 256 -pk 8000000000000000000 -pke fffffffffffffffffff -w 30 -htsz 28 -pb 02BF6E9A6F10A15DC828E968FC96CF9BC80A98F42227CCBE2AC4947B637B3E8FB1
Number of GPU threads set to #512
Number of GPU blocks set to #72
Number of pparam set to #256
Range begin: 0x8000000000000000000
Range end: 0xfffffffffffffffffff
Items number set to 2^30
HT size number set to 2^28
Pubkey set to 02bf6e9a6f10a15dc828e968fc96cf9bc80a98f42227ccbe2ac4947b637b3e8fb1
APP VERSION: 1.7.3
Found 1 Cuda device.
Cuda device:NVIDIA GeForce RTX 2070 (7173.000/8191MB)
Device have: MP:36 Cores+2304
Try -t 512 -b 72 -p 304 -w 30 -htsz 28 [7170.000 MB] Gen RAM[28672 MB]
---------------
Current config hash[d4b0aa674cd6f609feedc322743bf9fdb571f06c]
GiantSUBvalue:0000000000000000000000000000000000000000000000000000000080000000
GiantSUBpubkey: 025318f9b1a2697010c5ac235e9af475a8c7e5419f33d47b18d33feeb329eb99a4
*******************************
Total GPU Memory Need: 7008.000Mb
*******************************
Both HT files exist
Load BIN file:79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798_1073741824_268435456_htGPU.BIN
[0] chunk:1073741824b
[1] chunk:1073741824b
[2] chunk:1073741824b
[3] chunk:1073741824b
[4] chunk:1073741824b
[5] chunk:1073741824b
Generate Giants Buffer: 9437184 items
Load BIN file:512_72_256_1073741824_g2.BIN
[0] chunk:603979776b
Done in 00:00:01s
GPU count #1
GPU #0 launched
GPU #0 Free memory: 7171Mb
GPU #0 Total memory: 8191Mb
GPU #0 TotalBuff: 7008.000Mb
Load BIN file:79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798_1073741824_268435456_htCPU.BIN
[0] chunk:1073741824b
[1] chunk:1073741824b
[2] chunk:1073741824b
[3] chunk:1073741824b
[4] chunk:1073741824b
[5] chunk:1073741824b
[6] chunk:1073741824b
[7] chunk:1073741824b
[8] chunk:1073741824b
[9] chunk:1073741824b
START RANGE= 0000000000000000000000000000000000000000000008000000000000000000
END RANGE= 000000000000000000000000000000000000000000000fffffffffffffffffff
WIDTH RANGE= 0000000000000000000000000000000000000000000007ffffffffffffffffff
SUBpoint= (107460520eec5c741683329a716622b0b81c03200807de973686f8800b188cbb, 541a2b3f65dea673cacd9464630ab5eedbd1f28b7231c259fe2849c8e0d8db0b)
Save work every 180 seconds
FINDpubkey: 02bf6e9a6f10a15dc828e968fc96cf9bc80a98f42227ccbe2ac4947b637b3e8fb1
Cnt:658ec0000000000001 [1][ 722 ] = 722 MKeys/s x2^31=2^60.50 t:00:20:01
KEY[1]: 0x000000000000000000000000000000000000000000000865ce114686a1301a4c
Pub: 02bf6e9a6f10a15dc828e968fc96cf9bc80a98f42227ccbe2ac4947b637b3e8fb1
Working time 00:20:03s
Total time 00:21:47s
GPU#0 job finished
GPU#0 thread finished
cuda finished ok
Code:
C:\Users\Laurent>C:\Users\Laurent\Documents\Bitcoin\Kangaroo2.2.exe -t 6 -gpu -d 14 -o resultkang76.txt -ws Kang76.txt
Kangaroo v2.2
Start:8000000000000000000
Stop :FFFFFFFFFFFFFFFFFFF
Keys :1
Number of CPU thread: 6
Range width: 2^75
Jump Avg distance: 2^37.02
Number of kangaroos: 2^20.18
Suggested DP: 14
Expected operations: 2^38.60
Expected RAM: 982.1MB
DP size: 14 [0xFFFC000000000000]
SolveKeyCPU Thread 1: 1024 kangaroos
SolveKeyCPU Thread 2: 1024 kangaroos
SolveKeyCPU Thread 5: 1024 kangaroos
SolveKeyCPU Thread 4: 1024 kangaroos
SolveKeyCPU Thread 3: 1024 kangaroos
SolveKeyCPU Thread 0: 1024 kangaroos
GPU: GPU #0 NVIDIA GeForce RTX 2070 (36x64 cores) Grid(72x128) (97.0 MB used)
SolveKeyGPU Thread GPU#0: creating kangaroos...
SolveKeyGPU Thread GPU#0: 2^20.17 kangaroos [4.6s]
[660.58 MK/s][GPU 619.62 MK/s][Count 2^39.09][Dead 1][17:50 (Avg 10:30)][1.1/1.3GB] MB]
Done: Total time 18:07
80 bit pubkey 02b7e1f6b67c5c09ab3de91dcbe456716b98e7eb807f9c80160a5dea6e242e41bc
Code:
C:\Users\Laurent>C:\Users\Laurent\Documents\Bitcoin\Kangaroo2.2.exe -t 6 -gpu -d 16 -o resultkang80.txt -ws Kang80.txt
Kangaroo v2.2
Start:80000000000000000000
Stop :FFFFFFFFFFFFFFFFFFFF
Keys :1
Number of CPU thread: 6
Range width: 2^79
Jump Avg distance: 2^38.96
Number of kangaroos: 2^20.18
Suggested DP: 16
Expected operations: 2^40.60
Expected RAM: 982.1MB
DP size: 16 [0xFFFF000000000000]
SolveKeyCPU Thread 4: 1024 kangaroos
SolveKeyCPU Thread 5: 1024 kangaroos
SolveKeyCPU Thread 1: 1024 kangaroos
SolveKeyCPU Thread 3: 1024 kangaroos
SolveKeyCPU Thread 2: 1024 kangaroos
SolveKeyCPU Thread 0: 1024 kangaroos
GPU: GPU #0 NVIDIA GeForce RTX 2070 (36x64 cores) Grid(72x128) (97.0 MB used)
SolveKeyGPU Thread GPU#0: creating kangaroos...
SolveKeyGPU Thread GPU#0: 2^20.17 kangaroos [5.0s]
[648.05 MK/s][GPU 603.01 MK/s][Count 2^41.31][Dead 2][01:19:35 (Avg 42:51)][1.2/1.6GB]
Done: Total time 01:19:58
Code:
C:\Users\Laurent>C:\Users\Laurent\Documents\Bitcoin\BSGSgpu.exe -t 512 -b 72 -p 256 -pk 80000000000000000000 -pke ffffffffffffffffffff -w 30 -htsz 28 -pb 02b7e1f6b67c5c09ab3de91dcbe456716b98e7eb807f9c80160a5dea6e242e41bc
Number of GPU threads set to #512
Number of GPU blocks set to #72
Number of pparam set to #256
Range begin: 0x80000000000000000000
Range end: 0xffffffffffffffffffff
Items number set to 2^30
HT size number set to 2^28
Pubkey set to 02b7e1f6b67c5c09ab3de91dcbe456716b98e7eb807f9c80160a5dea6e242e41bc
APP VERSION: 1.7.3
Found 1 Cuda device.
Cuda device:NVIDIA GeForce RTX 2070 (7173.000/8191MB)
Device have: MP:36 Cores+2304
Try -t 512 -b 72 -p 304 -w 30 -htsz 28 [7170.000 MB] Gen RAM[28672 MB]
---------------
Current config hash[1e744f24cca3231323c65c9831191e62c175fcc5]
GiantSUBvalue:0000000000000000000000000000000000000000000000000000000080000000
GiantSUBpubkey: 025318f9b1a2697010c5ac235e9af475a8c7e5419f33d47b18d33feeb329eb99a4
*******************************
Total GPU Memory Need: 7008.000Mb
*******************************
Both HT files exist
Load BIN file:79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798_1073741824_268435456_htGPU.BIN
[0] chunk:1073741824b
[1] chunk:1073741824b
[2] chunk:1073741824b
[3] chunk:1073741824b
[4] chunk:1073741824b
[5] chunk:1073741824b
Generate Giants Buffer: 9437184 items
Load BIN file:512_72_256_1073741824_g2.BIN
[0] chunk:603979776b
Done in 00:00:01s
GPU count #1
GPU #0 launched
GPU #0 Free memory: 7171Mb
GPU #0 Total memory: 8191Mb
GPU #0 TotalBuff: 7008.000Mb
Load BIN file:79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798_1073741824_268435456_htCPU.BIN
[0] chunk:1073741824b
[1] chunk:1073741824b
[2] chunk:1073741824b
[3] chunk:1073741824b
[4] chunk:1073741824b
[5] chunk:1073741824b
[6] chunk:1073741824b
[7] chunk:1073741824b
[8] chunk:1073741824b
[9] chunk:1073741824b
START RANGE= 0000000000000000000000000000000000000000000080000000000000000000
END RANGE= 00000000000000000000000000000000000000000000ffffffffffffffffffff
WIDTH RANGE= 000000000000000000000000000000000000000000007fffffffffffffffffff
SUBpoint= (769bc75842bff58edc8366ecd78f8950ee4ab2e81359d90f9921fa3d2c4561be, b407e8c9d0187c4537231b3108c0a2b8be5e888984878c522a6df3ff4f2693d0)
Save work every 180 seconds
FINDpubkey: 02b7e1f6b67c5c09ab3de91dcbe456716b98e7eb807f9c80160a5dea6e242e41bc
Cnt:ef1ea0000000000001 [1][ 699 ] = 699 MKeys/s x2^31=2^60.45 t:00:46:58
Yeah that’s already a thing…for at least 2 years now.
So bitcrack and vanity can search for public key alone?Although there are tools for that, we are limited by the fact that you would have to know the public key of your target addresses. I have 250,000 pulic keys of the richest addresses, updated every month, but the problem is i would have to be searching for those in the 253-256 bit to ever dream of finding the private key. Since this is almost ALMOST impossible to achieve, pub key cracking should only be used on puzzle addresses and even those are in the high bit range i.e 125-160 bits . That's why i was originally talking about searching through pure private key cracking. Which gets me to the previous point of hash160 prefix. You're right, prefixing h160 would break the function. Looks like we're gonna stick to conventional ways.
Yeah that’s already a thing…for at least 2 years now.
So bitcrack and vanity can search for public key alone?Yeah that’s already a thing…for at least 2 years now.
So bitcrack and vanity can search for public key alone? And even better, what if we can apply the prefix concept on hash160 too. Instead of looking for address prefix, we look for hash160 prefix. Even more speed. In fact, this would be the fastest way ever.
Won't work, rmd160 has 40 characters and by searching for their prefix, should we stop hashing half way? Meaning converting sha256 hash of public key into rmd160 but only looking for a specific prefix, either we generate the whole hash and compare with our target or we can't generate just a prefix to compare because it would break the function and we wouldn't know the result.About brute force tools, bitcrack, vanity etc they all convert rmd160 to address, otherwise why would they accept an address as an input to check against?
I also believe it converts the partial strings to 160 as well; I’d have to recheck on that but I’m pretty sure it does.
Jump to: