Is it possible with the help of a key hunt to make base58 > hash160?
All functionality is available, someone even created it for windows.
https://github.com/kanhavishva/b58dec
This can be useful for preparing a bloom filter for Brainflayer.
Topic: Keyhunt - development requests - bug reports - page 24. (Read 13565 times)
Ok, I hope you get lucky and get the keys for some nice wallets, like microstrategy's or tesla's, and then I wish you luck in the court 
He who owns the private key, owns the cryptocurrency and that's a fact.
Well, in this case, is 100% legal! 
Legal.
Cryptocurrency rule: Whoever has the private key is the owner.
Cryptocurrency rule: Whoever has the private key is the owner.
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
Jump to: