where the processed keys are stored, why the RAM consumption has not increased in 8 days, only 5.5 MB ?  You got your DP set at 64, you got to go through 2^64 keys to get a DP, lower your DP so you can collect more DP's. Then you need to save your DP's, example: Kangaroo.exe -ws -w save.work -wi 30 in.txt |
|
|
|
is there a bsgs gpu version out there, anywhere guys? any news under the sun, love to read something new and great once again in here,  Its not a BSGS with a GPU yet and no new updates yet. |
|
|
|
How can i use saved work file for another public key?
You can't do that, you will have to start over with a new public key. |
|
|
|
|
I'm getting tired of every other post about bounty hunters, they should do something else that can at least guaranteed them money then instead of whining and complaining when the bounty hunters are the main ones that's quick to dump the coins to make a few bucks. The bounty hunters are to blame for how they get treated. If you're still a bounty hunter in 2020 and beyond that, just find something else to do.
|
|
|
|
Jean_Luc, from your github readme:
A Pollard's kangaroo interval ECDLP solver for SECP256K1 (based on VanitySearch engine).
This program is limited to a 125bit interval search.
Did you make a program limit up to 125bit search space or mentioned this just for practical reasons?
this is for the GPU, but there is no limit for the CPU Where did you see that? |
|
|
|
Specify the range of keys to search. For example, if you want to search in a specific range of private keys you can specify it in hex or decimal in the format START:END with a specified stride/increment size.
+1 need this function too , with keyspace start: end , with a specified stride/increment size.
like stride 10000:10000, with user define in stride and checkkeys
example user define
check keys 10000
stride keys 10000
this func make Vanitysearch more attractive and chances of probability build up
Can you give an example of the cmd line |
|
|
|
Jean_Luc, from your github readme:
A Pollard's kangaroo interval ECDLP solver for SECP256K1 (based on VanitySearch engine).
This program is limited to a 125bit interval search.
Did you make a program limit up to 125bit search space or mentioned this just for practical reasons?
Searching on range larger than 126 bits will decrease performance a lot.
If you want to modify the code, the modification are not very difficult.
You have to change the structure and the interface in the HashTable to accept larger distance and restore 256 bit distance in the GPU code.
There you have it...the man, the myth, the coding legend has spoken. If it takes 256 V100 Teslas roughly 45-60 days for 120 bit range search, I can't imagine how long it would take to search a 256 bit range. I would recommend adjusting ranges or search the bottom 124 bit range of larger range. But that's just me. If Jean Luc tells me what to adjust in the code, I will make the changes and post a 256 bit range Kangaroo program...for those who wish to have it. |
|
|
|
Vanitysearch starts with a seed which, if not specified by the user, is generated randomly. It proceeds from there searching sequentially. If you use the same seed, you will get the same results.
It's perfectly secure to do this. Searching this way creates an infinitesimal bias in the keys that are selected (the selected key is more likely to be found after a long run of non-matches than after an immediately prior match) but even where an attacker knows the exact prefix searched for the bias is extremely tiny-- because nearly spaced solutions are extremely unlikely to begin with-- and not exploitable (because you can't search only keys that meet that criteria... since the criteria itself requires generating the pubkeys to check). So its kind of pointless to try to find a address with this if you don't know seed. What exactly is the search space when searching with vanitysearch is it 2^160 or 2^96? |
|
|
|
Hello everyone I decided to join you, but I have a weak hardware, so I won't be able to win by consistently, hope for a random. Did I set up the program correctly?   Yes that setup you're using is correct. |
|
|
|
does it not calculate private keys? Is it not possible to select from the list of addresses?
No, that program as is, you can't modify or do anything else with it. |
|
|
|
only the CPU has a chance because the addresses were created on the CPU, you can wait for the same thermal noise that Intel uses as a source of entropy. But the video card will not be able to find the key because the addresses were created on the CPU, and the probability of a random match is negligible. For this reason, the pool LBC finds an addresses, it uses processors, otherwise it would not be possible https://lbc.cryptoguru.org/trophies An example:
We have a hardware capable of generating 1GKey/s and we have an input list of 106 addresses, the following table shows the probability of finding a collision after a certain amount of time:
Time Probability
1 second 6.8e-34
1 minute 4e-32
1 hour 2.4e-30
1 day 5.9e-29
1 year 2.1e-26
10 years 2.1e-25
1000 years 2.1e-23
Age of earth 8.64e-17
Age of universe 2.8e-16 (much less than winning at the lottery)LBC generates keys in incremental mode starting from key 1, so it won't find no more collisions really it stop at bit 54 and the same goes with bitcrack too. |
|
|
|
That's where y'all get it wrong at, y'all keep trying to brute force the whole space. You have to know exactly where the range of the address is in then brute force that. But you can't know within what range was the private key of the address once it was chosen. Can you explain it a little more? I'm not an expert. First of all you should be going after addresses with its public key already exposed. That's 2^128 search range right there. You should be generating addresses/keys from the desired public key. The next step would be to find a partial collision of the key and brute force the remaining of the key or half 2^128 to 2^64. is there a probability of calculating the key in 1 second? Its just 1 out of whatever the search range is |
|
|
|
Core i5 4t
Vanytygen64 - 550 kkeys per second
Vanitysearch - 5 mkeys per second
how can I import 580,000 addresses to check at the same time, will it slow down the speed?
Use the -i inputfile |
|
|
|
First of all you should be going after addresses with its public key already exposed. That's 2^128 search range right there. You should be generating addresses/keys from the desired public key. The next step would be to find a partial collision of the key and brute force the remaining of the key or half 2^128 to 2^64. Wait how is that possible? What can you do with a public key? Knowing the x and y axis won't benefit you on doing brute force. The possibilities of finding the same public key are 1 in 2 256. That's 2^128 search range right there. How did you conclude that? You need to read on this then https://bitcointalk.org/index.php?topic=5244940.0https://github.com/JeanLucPons/KangarooSearching with the public key reduces the search space of 2^256 to 2^128. |
|
|
|
That's where y'all get it wrong at, y'all keep trying to brute force the whole space. You have to know exactly where the range of the address is in then brute force that. But you can't know within what range was the private key of the address once it was chosen. Can you explain it a little more? I'm not an expert. First of all you should be going after addresses with its public key already exposed. That's 2^128 search range right there. You should be generating addresses/keys from the desired public key. The next step would be to find a partial collision of the key and brute force the remaining of the key or half 2^128 to 2^64. |
|
|
|
I just did a small research about how difficult it is to guess a bitcoin address. All private keys are 2256 but the total addresses aren't that many. They are 2160 as @nullius said.
Now let's compare 2160 with another huge number:
14,615,016,400,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 (2160)
133,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 (Total atoms that exist on our planet)
That answer comes from an estimation of the number of atoms in each of Earth's elements, like Iron, Oxygen, Silicon, Magnesium, Sulfur … etc
It's scary to think how many different combinations of addresses can exist. Imagine that one water drop contains about 5 sextillion atoms. (5.01 x 1021)
Imagine picking one atom randomly from the earth and expecting someone to guess it.
When your computer generates an address is like picking one atom from ~10,000 different Earths.
You can't brute force a bitcoin address. You just can't.
That's where y'all get it wrong at, y'all keep trying to brute force the whole space. You have to know exactly where the range of the address is in then brute force that. |
|
|
|
there is no difference between 1 and 580000 addresses, the speed is limited by the random number generator
why can't I set more than 19 characters to Vanitygen64, in case I get lucky and the whole address is generated quickly? Probably the fact is that this is a calculation and not a random generation, faster than the estimated time calculation is impossible, unlike random generenation in another program
This one you can put in the whole address https://bitcointalk.org/index.php?topic=5112311.0https://github.com/JeanLucPons/VanitySearch |
|
|
|
I only know the address and public key, and I want to use them to calculate the private key
Run the program and you will see the calculation. |
|
|
|
it takes a million years to select one address, but 2 years is enough to select one of 590 thousands 1+ BTC addresses
however, 12000 keys per second is very small on the processor, how much will the video card give if you write the same program?
At 12000 keys per second, you're not hitting no address at that speed. Depends on where the program searching at. How did you come up with 2 years for 590k address because that's not enough addresses to check for in a big space. And you do know 1+ btc addresses is no different than 100+ btc addresses. |
|
|
|
Baloney. Well, have fun trying, as I said.
Good link ( forum thread), but it needs the public key. It will not work with a Bitcoin address. Also, if you think that it will crack public keys in a reasonable time—as I said, have fun trying! Who cares what you said, I said it wouldn't take a million years. I never said it it would crack in a reasonable time! |
|
|
|
|
Show Posts
