Understood, I know that Kangaroo has a merge function and that is what made me wonder if there were more than 1 point to put together to get the answer. the problem is that 120 has such a large range using a GPU for it is like finding a specific speck of sand in the Sahara. Even with 100 GPU's it will all come down to really good luck.
Topic: Pollard's kangaroo ECDLP solver - page 54. (Read 60095 times)
Thanks for the answer. i always wondered because if there was just one point then why could I merge two files and solve the key with kangaroo unless there were at least two points to merge to give the answer. That would be the wild and tame?
Each wild point found has a tame match, somewhere in the range.Example, let's say private key is (keep it integer for ease of illustration) 1060
You could solve the key in many different ways, just depends on which tame and wild match first,
Tame 2000 and wild 940 would solve the key.
Tame 1100 and wild 40 would solve the key.
To solve when you merge files, one of the Tame points must match one of the Wild points. Then (for this program) T-W + beginning range = private key.
Thanks for the answer. i always wondered because if there was just one point then why could I merge two files and solve the key with kangaroo unless there were at least two points to merge to give the answer. That would be the wild and tame?
If K is unknown private key, W - known wild distance, T - known tame distance, then in case of collision (when wild and tame kangaroos meets in same distinguished point), you have the following equation: K+W = T whose solution is trivial.
Thanks for the answer. i always wondered because if there was just one point then why could I merge two files and solve the key with kangaroo unless there were at least two points to merge to give the answer. That would be the wild and tame?
So is the hex private key located at one specific point in the range which equals the hex private key address or is the key spread out and is the addition of different points in the range. If the latter it would not make sense to search in portions of the entire range like dividing the search into 0 through F individually
It's located at one specific point.
Kangaroo does not split up the search range - that would be a waste of time as you said - instead the algorithm bounces between different points in the range, using a random walk, at each iteration, until two points collide.
Kangaroo bounces two sets of about a thousand points each (this kind of cluster of points is called a herd - and 1000 is a hard-coded constant) at a time per iteration, for CPU and also GPU, to make the search parallel, and a match happens when two points from different sets collide.
I got an RTX 2060 GPU. I was testing it using Jean_Luc's vanitygen and kangaroo. With the vanitygen the speed was at least +900 MKeys and the kangaroo speed was doing between 500 and 600 MKeys. Is this normal or do I have the wrong configuration with kangaroo?
So is the hex private key located at one specific point in the range which equals the hex private key address or is the key spread out and is the addition of different points in the range. If the latter it would not make sense to search in portions of the entire range like dividing the search into 0 through F individually
If the address has never sent bitcoin then the public key is unknown and you either need to use bitcrack or altcrack to search with the public address or ripemd160.
How to convert adress of 30btc puzzle to public keys for kangaro?, adress not work
I want to add a condition to the parity to determine the direction of the jump.
if you can code
kangaroo.exe source code on github
you can fork to modify it as you want
I want to add a condition to the parity to determine the direction of the jump.
Hello,people.Is this setting searching randomly for the priv key of an address :
Kangaroo.exe -ws -w texgen.work -wi 30 in.txt? If not.how can i try my luck with random search? Is there any command?
Kangaroo.exe -ws -w texgen.work -wi 30 in.txt? If not.how can i try my luck with random search? Is there any command?
The normal mode technically is a pseudorandom search. It iterates through points chosen in a deterministic but very complex way because that's how the Pollard Kangaroo algorithm works.
Hello,people.Is this setting searching randomly for the priv key of an address :
Kangaroo.exe -ws -w texgen.work -wi 30 in.txt? If not.how can i try my luck with random search? Is there any command?
Kangaroo.exe -ws -w texgen.work -wi 30 in.txt? If not.how can i try my luck with random search? Is there any command?
I got an RTX 2060 GPU. I was testing it using Jean_Luc's vanitygen and kangaroo. With the vanitygen the speed was at least +900 MKeys and the kangaroo speed was doing between 500 and 600 MKeys. Is this normal or do I have the wrong configuration with kangaroo?
Sounds about right to me. Vanitysearch is always going to appear faster than Kangaroo because of the former's use of endomorphisms to check several privkeys at once.
I got an RTX 2060 GPU. I was testing it using Jean_Luc's vanitygen and kangaroo. With the vanitygen the speed was at least +900 MKeys and the kangaroo speed was doing between 500 and 600 MKeys. Is this normal or do I have the wrong configuration with kangaroo?
Out of curiosity, I was testing a range 0-FFFFFFFFFFFF and found the private key very quickly. I then proceeded to test the next range 1000000000000-1FFFFFFFFFFFF of equivalent size but with a public key of the first keyspace. It still managed to solve for the private key, even though the private key wasn't in the range provided. It took about 5 minutes. Why is that?
Maybe because the range is very small? And how come it found a key that wasn't there? That's a contadiction
lesser range = 0-FFFFFFFFFFFF
greater range = 1000000000000-1FFFFFFFFFFFF
Let's say priv key to pub key is 3103FFCB8A82
This program always starts from 0. So if user enters the range of:
1000000000000:1FFFFFFFFFFFF
the program automatically subtracts the beginning range and shifts the pub key accordingly, in this case it subtracts and shifts by 1000000000000; so the program is actually searching from:
0:FFFFFFFFFFFF
If pubkey is found, the program calculates key like so: Tame D - Wild D + (original beginning range) 1000000000000
Makes perfect sense! Just not very efficient for finding that lesser private key. I wonder if that could be optimized?
But the good news is, you know the program can find a key in a lesser range, even if your inputted range is greater.
Try running the program again with greater range with lesser key and see if it takes 5 minutes every time.
Remember, Pollard's Kangaroo/Lambda is designed to find a key in a known range (a, b).
Out of curiosity, I was testing a range 0-FFFFFFFFFFFF and found the private key very quickly. I then proceeded to test the next range 1000000000000-1FFFFFFFFFFFF of equivalent size but with a public key of the first keyspace. It still managed to solve for the private key, even though the private key wasn't in the range provided. It took about 5 minutes. Why is that?
Maybe because the range is very small? And how come it found a key that wasn't there? That's a contadiction
lesser range = 0-FFFFFFFFFFFF
greater range = 1000000000000-1FFFFFFFFFFFF
Let's say priv key to pub key is 3103FFCB8A82
This program always starts from 0. So if user enters the range of:
1000000000000:1FFFFFFFFFFFF
the program automatically subtracts the beginning range and shifts the pub key accordingly, in this case it subtracts and shifts by 1000000000000; so the program is actually searching from:
0:FFFFFFFFFFFF
If pubkey is found, the program calculates key like so: Tame D - Wild D + (original beginning range) 1000000000000
Makes perfect sense! Just not very efficient for finding that lesser private key. I wonder if that could be optimized?
Out of curiosity, I was testing a range 0-FFFFFFFFFFFF and found the private key very quickly. I then proceeded to test the next range 1000000000000-1FFFFFFFFFFFF of equivalent size but with a public key of the first keyspace. It still managed to solve for the private key, even though the private key wasn't in the range provided. It took about 5 minutes. Why is that?
Maybe because the range is very small? And how come it found a key that wasn't there? That's a contadiction
lesser range = 0-FFFFFFFFFFFF
greater range = 1000000000000-1FFFFFFFFFFFF
Let's say priv key to pub key is 3103FFCB8A82
This program always starts from 0. So if user enters the range of:
1000000000000:1FFFFFFFFFFFF
the program automatically subtracts the beginning range and shifts the pub key accordingly, in this case it subtracts and shifts by 1000000000000; so the program is actually searching from:
0:FFFFFFFFFFFF
If pubkey is found, the program calculates key like so: Tame D - Wild D + (original beginning range) 1000000000000
Out of curiosity, I was testing a range 0-FFFFFFFFFFFF and found the private key very quickly. I then proceeded to test the next range 1000000000000-1FFFFFFFFFFFF of equivalent size but with a public key of the first keyspace. It still managed to solve for the private key, even though the private key wasn't in the range provided. It took about 5 minutes. Why is that?
Maybe because the range is very small? And how come it found a key that wasn't there? That's a contadiction
Out of curiosity, I was testing a range 0-FFFFFFFFFFFF and found the private key very quickly. I then proceeded to test the next range 1000000000000-1FFFFFFFFFFFF of equivalent size but with a public key of the first keyspace. It still managed to solve for the private key, even though the private key wasn't in the range provided. It took about 5 minutes. Why is that?
So what does 256 bits look like stored in a work file, I need to see an example.
AF4560D2458D74B963C5F3B7FD7A65ECF6A860C23BD1AC97B3A1121B2BC657D8 F1978DCDCDCDCC8D76C8C5DC5D85CD5C765C5D7C57D5C7D5C57D5C75D7C57D5C
256bits (space) 256bits
Jump to: