Topic: Keyhunt - development requests - bug reports - page 26. (Read 15202 times)
anyone wondering if this is legal, or nah... ?
trying to build it on Win10 with Cygwin and getting following mistake:
can anyone help me?
can anyone help me?
I recommend putting WSL2 and not bothering, a very convenient thing.
https://docs.microsoft.com/en-us/windows/wsl/install-win10
trying to build it on Win10 with Cygwin and getting following mistake:
can anyone help me?
can anyone help me?
I recommend putting WSL2 and not bothering, a very convenient thing.
https://docs.microsoft.com/en-us/windows/wsl/install-win10
What am I doing wrong?
How many lines can a file with public keys contain at most?
Code:
~/keyhunt$ ./keyhunt -m bsgs -f pubkeys.txt -r 1:fffffffffffff -t 12 -k 800
[+] Version 0.1.20210412 secp256k1
[+] Setting mode BSGS
[+] Setting 12 threads
[+] Setting k factor to 800
[+] Opening file pubkeys.txt
[+] Added 24190 points from file
[+] Setting N up to 17589233254400.
[+] Init 1st bloom filter for 3355443200 elements : 11502.00 MB
[+] Init 2nd bloom filter for 167772160 elements : 575.10 MB
[+] Allocating 0.6 MB for 5242 aMP Points
[+] Precalculating 5242 aMP points
[+] Allocating 2560.00 MB for 167772160 bP Points
[+] processing 3355443200/3355443200 bP points : 100%
[+] Sorting 167772160 elements... Done!
[+] Thread aff870000001
Total 0 keys in 30 seconds: 0 keys/s
Total 0 keys in 180 seconds: 0 keys/s
How many lines can a file with public keys contain at most?
trying to build it on Win10 with Cygwin and getting following mistake:
can anyone help me?
Code:
$ make
gcc -O3 -c bloom/bloom.c -o bloom.o
g++ -O3 -c sha256/sha256.c -o sha256.o
gcc -O3 -c base58/base58.c -o base58.o
gcc -O3 -c rmd160/rmd160.c -o rmd160.o
gcc -O3 -c sha3/sha3.c -o sha3.o
gcc -O3 -c xxhash/xxhash.c -o xxhash.o
g++ -O3 -c util.c -o util.o
g++ -m64 -mssse3 -Wno-unused-result -Wno-write-strings -O2 -c secp256k1/Int.cpp -o Int.o
g++ -m64 -mssse3 -Wno-unused-result -Wno-write-strings -O2 -c secp256k1/Point.cpp -o Point.o
g++ -m64 -mssse3 -Wno-unused-result -Wno-write-strings -O2 -c secp256k1/SECP256K1.cpp -o SECP256K1.o
g++ -m64 -mssse3 -Wno-unused-result -Wno-write-strings -O2 -c secp256k1/IntMod.cpp -o IntMod.o
g++ -m64 -mssse3 -Wno-unused-result -Wno-write-strings -O2 -c secp256k1/Random.cpp -o Random.o
g++ -m64 -mssse3 -Wno-unused-result -Wno-write-strings -O2 -c secp256k1/IntGroup.cpp -o IntGroup.o
g++ -o keyhunt keyhunt.c base58.o rmd160.o sha256.o bloom.o xxhash.o util.o Int.o Point.o SECP256K1.o IntMod.o Random.o IntGroup.o -lgmp -lm -lpthread
#gcc -O3 hexcharstoraw.c -o hexcharstoraw util.o -lm
g++ -o bPfile bPfile.c util.o -lgmp -lm
1. I launched:
The file is 90 GB and the process continues, how do I calculate the final file size and creation time?
___
2. A 100 GB file was created.
I don't notice any performance gain from bPfile.bin.
___
3. I run:
File 1-63 contains public keys 1 through 63 of the puzzle bits.
more than 1.5 hours passed, nothing went wrong, although if you make one public key of 63 bits, it finds it quickly.
upd. Understood, it was necessary to remove the -R parameter
It remains to understand whether the bPfile.bin file is necessary, since I did not notice any benefit from it, except for the 100GB of space on the ssd.
Code:
./bPfile 3355443200 bPfile.bin
___
2. A 100 GB file was created.
Code:
./keyhunt -m bsgs -f 50bit.txt -b 50 -R -k 800 -t 12
___
3. I run:
Code:
./keyhunt -m bsgs -f 1-63.txt -R -t 12 -r 0000000000000001:8000000000000000 -k 800
more than 1.5 hours passed, nothing went wrong, although if you make one public key of 63 bits, it finds it quickly.
upd. Understood, it was necessary to remove the -R parameter
It remains to understand whether the bPfile.bin file is necessary, since I did not notice any benefit from it, except for the 100GB of space on the ssd.
I'm just now seeing this, is this worth trying to use?
I am confused if 120 address and public key are compressed why do you say we need to use "uncompress" for 120?
Sorry that was a mistake, the program accept now both compress or uncompress.
Would someone explain please, what's the point of generating the bPfile.bin file? I run tests with it and without, the speed performance seems to be about the same.
Thank you.
Thank you.
If you are goin to stop and restart the program to often is better to have the bPfile already precalculate to save some time between stop/restart the program.
I need to make some test but Im pretty sure that the speed will be closer. BTW the bottleneck is the ECC Operations not the bloom filter
And find the public key.
It takes a long time. Nothing found.
What could be the problem?
It takes a long time. Nothing found.
What could be the problem?
You don't have idea of what are you doing right?
pub2rmd was a experiment it have the same difficulty of crack a 256 bit key.
regards!
Hello
I'm trying to run the program.
./keyhunt -m pub2rmd -f tests / puzzleswopublickey.txt -q -b 19
In the file puzzleswopublickey.txt I use only this key
ebfbe6819fcdebab061732ce91df7d586a037dee
And find the public key.
It takes a long time. Nothing found.
What could be the problem?
I'm trying to run the program.
./keyhunt -m pub2rmd -f tests / puzzleswopublickey.txt -q -b 19
In the file puzzleswopublickey.txt I use only this key
ebfbe6819fcdebab061732ce91df7d586a037dee
And find the public key.
It takes a long time. Nothing found.
What could be the problem?
You are supposed to tag & challenges mores faster of tools : https://github.com/FastFilter/xor_singleheader.git I just want ensure you to that it is cracking brute-forcing private key from public key or anything else..........
I think you can try xor filter, it's more faster.
https://github.com/FastFilter/xor_singleheader
https://github.com/FastFilter/xor_singleheader
Would someone explain please, what's the point of generating the bPfile.bin file? I run tests with it and without, the speed performance seems to be about the same.
Thank you.
Thank you.
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
120.txt
you can run the tool agains that file:
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
Code:
02CEB6CBBCDBDF5EF7150682150F4CE2C6F4807B349827DCDBDD1F2EFA885A2630
you can run the tool agains that file:
I am confused if 120 address and public key are compressed why do you say we need to use "uncompress" for 120?
Program works great but one question. On the BSGS function puzzle 120 only goes to
+] Setting mode BSGS
I tried the -r but it had no effect on increasing the range. Is this the limit of the space the program can scan? how do I increase the range to the end of the keyspace FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF?
+] Setting mode BSGS
- Min range: 800000000000000000000000000000
- Max range: 1000000000000000000000000000000
- Setting random mode.
- Setting k factor to 128 [
- Max range: 100000000000000000000000000000000[/b][/i][/i]
- Opening file tests/120.txt
- Added 1 points from file
- Bit Range 128
- Setting N up to 17592186044416.
- Init 1st bloom filter for 536870912 elements : 1840.00 MB
- Init 2nd bloom filter for 26843546 elements : 92.02 MB
- Allocating 3.8 MB for 32768 aMP Points
- Precalculating 32768 aMP points
- Allocating 409.60 MB for 26843546 bP Points
- processing 1950960/536870912 bP points : 0%
I tried the -r but it had no effect on increasing the range. Is this the limit of the space the program can scan? how do I increase the range to the end of the keyspace FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF?
Quote
Yes you are totally right this will be changed soon.
Im working in some migration from libgmp to the secp256k1 library used in the JLP BSGS Code, i already check that librery and with some hardware and code tricks it can be 4 or 5 times more faster for publickey generations, this will boots all the modes speed, address, rmd160, xpoint and bsgs mode in the code.
Im working in some migration from libgmp to the secp256k1 library used in the JLP BSGS Code, i already check that librery and with some hardware and code tricks it can be 4 or 5 times more faster for publickey generations, this will boots all the modes speed, address, rmd160, xpoint and bsgs mode in the code.
Good deal and good work you've done with your program.
4x 5x times faster? Now you just need to code for Windows users
Hi WanderingPhilospher, thanks for test the program.
Keyhunt use a Bloom filter to check if the generated address or hash is on the list, this will lead in some false positive collision (Error rate is one in a million or something like that), so if the the bloom filter return a positive result, it use a second check, this is a binary search over all the address or items in the list, it can dertermine if one item is on the list perfoming only log(N)/log(2) operation, for 15 Milllions of addres this process only take 24 comparations.
This is like the hash table but i prefer keep those separated becuase there are some trick with the bloom filter that allow you use a little less ram in the case of the BSGS mode.
And no, in keyhunt there are no key drop or anything like that.
Yes you are totally right this will be changed soon.
Im working in some migration from libgmp to the secp256k1 library used in the JLP BSGS Code, i already check that librery and with some hardware and code tricks it can be 4 or 5 times more faster for publickey generations, this will boost all the modes speeds, address, rmd160, xpoint and bsgs mode in the code.
Best regards!
I can get 1 MKey/s with a list of 15 million addresses (i5-4690 running 4 threads). I am curious, does/will your Keyhunt program handle that many addresses and if so, does the Key/s drop?
Keyhunt use a Bloom filter to check if the generated address or hash is on the list, this will lead in some false positive collision (Error rate is one in a million or something like that), so if the the bloom filter return a positive result, it use a second check, this is a binary search over all the address or items in the list, it can dertermine if one item is on the list perfoming only log(N)/log(2) operation, for 15 Milllions of addres this process only take 24 comparations.
This is like the hash table but i prefer keep those separated becuase there are some trick with the bloom filter that allow you use a little less ram in the case of the BSGS mode.
And no, in keyhunt there are no key drop or anything like that.
why not read the input file of full addresses, convert them to RIPE, and then do the search on RIPE?
Yes you are totally right this will be changed soon.
Im working in some migration from libgmp to the secp256k1 library used in the JLP BSGS Code, i already check that librery and with some hardware and code tricks it can be 4 or 5 times more faster for publickey generations, this will boost all the modes speeds, address, rmd160, xpoint and bsgs mode in the code.
Best regards!
Been doing some testing. I have a CPU only setup/program that takes an input file of full BTC addresses and randomly searches user defined keyspace.
I can get 1 MKey/s with a list of 15 million addresses (i5-4690 running 4 threads). I am curious, does/will your Keyhunt program handle that many addresses and if so, does the Key/s drop?
Also, I read your page and I have a suggestion for you. You say that searching RIPE is 2x faster than full address; why not read the input file of full addresses, convert them to RIPE, and then do the search on RIPE? Then you only have to have the one user option...to search for full address while under the hood, the program converts to RIPE and searches for RIPE. That's how my program works, C++ based off of VanitySearch (but CPU only).
I can get 1 MKey/s with a list of 15 million addresses (i5-4690 running 4 threads). I am curious, does/will your Keyhunt program handle that many addresses and if so, does the Key/s drop?
Also, I read your page and I have a suggestion for you. You say that searching RIPE is 2x faster than full address; why not read the input file of full addresses, convert them to RIPE, and then do the search on RIPE? Then you only have to have the one user option...to search for full address while under the hood, the program converts to RIPE and searches for RIPE. That's how my program works, C++ based off of VanitySearch (but CPU only).
Is working, what is your doubt?
Not doubt, just not understanding.
Thread 0: 0000000000000000000000000000000000a000000000000000d4a00000000000
Thread 0: 0000000000000000000000000000000000a0000000000000011bb00000000000
Why are right hand bytes always zero on update ? Is it because the program just displays at that range and everything in between d4a00000000000 and 11bb00000000000 is not shown?
Thanks again for a great program
I was looking at the source code and as some other users already commented, it would be awesome to run it with Cuda cores or OpenSL, that way we could try tons of keys with the right GPU mining rig... But looks like a complex task.
I will add it later, long later, first im solving some bugs and improving the general speed in CPU
If I hit that 64 jackpot y will share a tip with OP, Odds are null but the only way to do it is trying.
Good luck, actually we have better chances to hit the #64 with some megakeys/s than the 120 with Petakeys/s
A False collision ignored, just the 64th bit keyspace scanning. bsgs_hybrid
thanks for the help
thanks for the help
Yes he told me something about that issue, i will send him your message.
BTW guys i just publish a video on youtube about keyhunt.
https://youtu.be/k3698rhRUzg
I hope you like it.
Best regards!
hi albert0bsd, this one is for iceland, kangrand
i keep getting
0x02D822FAC57DB1CA1E060581969B0247A388C46F331FEC84307121328B08FD4E66 Aborted !
and now for you albert0bsd
i keep getting false collisions with the same pubkeys
MK/s][Count 2^37.92][Dead 2][34:17 (Avg 29:02)][2.0/4.0MB]
Key# 1 [XX]Pub: 0x02A46B582948835B0D715E5F5EAA34ABADB8C1E221C8E1A5FD3773CDC3EC1C2C5B
Aborted !
A False collision ignored, just the 64th bit keyspace scanning. bsgs_hybrid
thanks for the help
i guess it fixed itself. thanks for your great software,
i keep getting
0x02D822FAC57DB1CA1E060581969B0247A388C46F331FEC84307121328B08FD4E66 Aborted !
and now for you albert0bsd
i keep getting false collisions with the same pubkeys
MK/s][Count 2^37.92][Dead 2][34:17 (Avg 29:02)][2.0/4.0MB]
Key# 1 [XX]Pub: 0x02A46B582948835B0D715E5F5EAA34ABADB8C1E221C8E1A5FD3773CDC3EC1C2C5B
Aborted !
A False collision ignored, just the 64th bit keyspace scanning. bsgs_hybrid
thanks for the help
i guess it fixed itself. thanks for your great software,
Jump to: