Topic: Keyhunt - development requests - bug reports - page 17. (Read 11571 times)

Great information to share!! How to use pfile??

I want to open this thread to talk about the tool that i develop Keyhunt available on github.

https://github.com/albertobsd/keyhunt

Keyhunt use the BSGS algorimth to find privatekeys with the publickey, the program runs on CPU and make several use of RAM to boost the speed.

To try to find the privatekey from the 120 puzzle you need to add this publickey "uncompress" to a txt file:

How to use

• Add the publickey to a file

120.txt

you can run the tool agains that file:



output


Speed: 1 Terakeys/s

Well in that example (same in github) we can reach 1Terakeys/s with one thread.

Wan to more speed? use the "-k value" param to boots the speed


Output:


Speed: ~23 Terekeys/s

Tips

• you can quiet the thread output with -q
• you can load the precalcutalted bPtable -p yourfile.bin

Do you still want to more speed? Well Use more RAM, the -k 128 will use some 2.5 GB of RAM

This file will take some minutes for the value -k 128, but the speed worth it!


Output:


Speed: ~146 Terakeys/s one single thread

OK at this point maybe you want to use ALL your RAM memory to solve the puzzle 120, just a bigger -k value

I already tested it with some 24 GB used with -k 1024 and I get 1.16 Petakeys/s per thread.

Using the same configuration with 4 threads I get 4.5 Petakeys/s total

Image:

---

FAQ

Q: Why the Progress is not displayed?
R: The speed depent of the number of target publickeys if you load 1000 publickeys, it will take some more time, the speed is only displayed when at least one thread finish one of his cycles

Q: Can we faster this code with Gpu?
R: Well yes, but the BSGS algo use RAM, only high end video cards have a lot of RAM, for GPU is better to use Kangaroo

Q: How long will take the scan the 120 bit range?
R: Human brain usually can't handle big numbers, the 120 bit space have 664613997892457936451903530140172287 (six hundred sixty four decillion...) and we speed is about 1000000000000 (one trillion or one terakey/s) the spected time acording with your speed is:

Q: Why should i keep using brute force tools?
R: You should not, but people hope in luck.

Q: Is avaible for Windows?
R: Natively no, but you can install the ubuntu shell for windows and compile it from there

Q: It have dependencies?
R: Just libgmp for BigIntegers install it with


Q: Why your program use alot of RAM?
R: Actuallly i keep in RAM two things (Bloomfilter and a Full bPTable ) im working in one way to remove or reduce the bPTable.

---

Nexts releases

• BSGS with K factor Release in 6/March
• Network/Pool versión
• Pollard rho

Best regards!

hi albert
@cixegz this user question https://bitcointalksearch.org/topic/m.58874670
its posible algebra and math tricks use to guess y odd is small or big range
                                                                           y even is small or big Roll Eyes range

He already has that, its called pub2rmd mode its under Experimental modes

https://github.com/albertobsd/keyhunt#pub2rmd-mode

Dear albertobsd,
can you develop an or is there algorithm to try to get public keys of the unsolved puzzles? example; puzzle 64, 66, 67, 68?
if we get the publickeys, the puzzles would be solved in less than minute.
Thanks in advance.

Dear albertobsd,
can you develop an or is there algorithm to try to get public keys of the unsolved puzzles? example; puzzle 64, 66, 67, 68?
if we get the publickeys, the puzzles would be solved in less than minute.
Thanks in advance.

Alberto,
Is there any road map for the project? Do you want to focus on new features or do you prefer to focus on improving performance of the existing code?
What about splitting code to avoid unnecessary ifs/switches?
Any plans to introduce stride?

What about splitting code to avoid unnecessary ifs/switches?

Any plans to introduce stride?

Hello albertobsd i have a Questions outside and inside this awesome program that you have made.
i've been looking for correct answers for weeks, but everyone says differently so your the one who to ask, because you're a bitcoin expert here.
Questions:


So total  possible public keys are 2^256 and are mapped to a set of 2^160 (160 bits) addresses. Since there are more public keys and private keys than addresses, but every public key can be mapped to an 160 bits address, there must be then in average 2^256 / 2^160 = 2^96 keys to each address. so if there are 2^96 addresses for each bitcoin address, so does all that 2^96 addresses that one Address have, share ALL the same public key? because that's what you need  in order to have the same RIPEMD-160 hash. so only private key which changes, not public key with the 2^96 key possible keys per Address right?

==========

Another Question related:

So if all my thoughts are right, then from what i understood, All addresses of bitcoin exists only 1 TIME from the range ( 160 bits ) 0 - ( FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF ), and the rest 2^96 addresses per address start to exists after the range of 2^160, so starting from 2^161. Is that also correct?


==========


Last Question.

Then if bitcoin addresses have 160 bits, can't we just try to Bruteforce that 160 bits from ( 0 - FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF )  Hex-Range with  high number of  Random peta/keys checks - - using BSGS, won't we have a 1 of 2^160 chance of unlocking any addresses that have the public key? can that work using BSGS right, or with BSGS that method doesn't work? (even with low chance, i still believe in luck)

==========

if you could answer all this three Question, then i really appreciate it!
Best regards.

Let me ask this about keyhunt, if we are searching for public keys, how come we have to search in the whole range? For example, if we are looking for key #120 we have to search in the whole range of 2^120?

Let me ask this about keyhunt, if we are searching for public keys, how come we have to search in the whole range? For example, if we are looking for key #120 we have to search in the whole range of 2^120?

Did you mean "one private key may generate two different addresses, depending which public key is used"?

and that's true that it would be possible that uncompressed public key from one priv key generates the same address as compressed pubkey from another priv key.

Also one address can be generated from compressed or uncompressed publickey

So total  possible public keys are 2^256 and are mapped to a set of 2^160 (160 bits) addresses. Since there are more public keys and private keys than addresses, but every public key can be mapped to an 160 bits address, there must be then in average 2^256 / 2^160 = 2^96 keys to each address. so if there are 2^96 addresses for each bitcoin address, so does all that 2^96 addresses that one Address have, share ALL the same public key? because that's what you need  in order to have the same RIPEMD-160 hash. so only private key which changes, not public key with the 2^96 key possible keys per Address right?

So if all my thoughts are right, then from what i understood, All addresses of bitcoin exists only 1 TIME from the range ( 160 bits ) 0 - ( FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF ), and the rest 2^96 addresses per address start to exists after the range of 2^160, so starting from 2^161. Is that also correct?

Then if bitcoin addresses have 160 bits, can't we just try to Bruteforce that 160 bits from ( 0 - FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF )  Hex-Range with  high number of  Random peta/keys checks - - using BSGS, won't we have a 1 of 2^160 chance of unlocking any addresses that have the public key? can that work using BSGS right, or with BSGS that method doesn't work? (even with low chance, i still believe in luck)

@albertobsd

iknow r s1s2  value
i need z1z2 how to calculate