albertobsd / keyhunt Goto Github PK

Hello. When searching for thousands of keys, it does not show the progress and speed. Screenshot here

After running make gives me this output:

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/string.h:145:9: error: conflicting types for 'memset'
errno_t memset_s(void *__s, rsize_t __smax, int __c, rsize_t __n) __OSX_AVAILABLE_STARTING(__MAC_10_9, __IPHONE_7_0);
        ^
<command line>:1:29: note: expanded from here
#define memset_s(W,WL,V,OL) memset(W,V,OL)
                            ^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/string.h:74:7: note: previous declaration is here
void    *memset(void *__b, int __c, size_t __len);
         ^
1 error generated.
make: *** [default] Error 1

$ ./keyhunt -m bsgs -f 33.txt -b 32
[+] Version 0.1.20210331
[+] Setting mode BSGS
[+] Min range: 80000000
[+] Max range: 100000000
[+] Opening file 33.txt
[+] Added 1 points from file
[+] Bit Range 32
[+] Setting N up to 532245221049948222.
[E] error bloom_init [0]

Extrange, i need to check that bug...

Hi there,
thank you for your app. It looks interesting. But why it displays incorrect speed?
I'm running it on Debian
Screenshot - https://drive.google.com/file/d/1Edr1Cl1XwyOOf20k2M9gx-JIbkIR0YsG/view?usp=sharing

Dear Alberto!
Can you tell me what is the meaning of "Sorting elements" string?
It takes a lot of time to proceed this step. Is it possible to fasten it somehow?

what are the parameters for 64GB memory
he always puts me 1410065408

PS **> .\bPfile.exe 10000000000 bPfile.bin
[+] precalculating 1410065408 bP elements in file bPfile.bin

Good Day @albertobsd ,

I observed when I run keyhunt it is not utilizing the swap. Is there way to load bloom filter elements in Swap either fully or partially?

Thank you
Regards

Some user without github report this one.

~/alberto/keyhunt$ ./keyhunt -m bsgs -f 120.txt -r 800000000000000022000000000000:800000000000000022f00000000000 -t 4
[+] Version 0.1.20210306 K*BSGS
[+] Setting mode BSGS
[+] Setting 4 threads
[+] Opening file 120.txt
[+] Added 1 points from file
[+] Setting N up to 17592186044416.
[+] Init bloom filter for 4194304 elements : 11.00 MB
[+] Allocating 128.00 MB for aMP Points
[+] Precalculating 4194304 aMP points
[+] Allocating 64.00 MB for bP Points
[+] precalculating 4194304 bP points
[+] Sorting 4194304 elements
[+] Thread 0: 0000000000000000000000000000000000800000000000000022000000000000
[+] Thread 1: 0000000000000000000000000000000000800000000000000022100000000000
[+] Thread 2: 0000000000000000000000000000000000800000000000000022200000000000
[+] Thread 3: 0000000000000000000000000000000000800000000000000022300000000000
[+] Thread 1: 0000000000000000000000000000000000800000000000000022400000000000
[+] Thread 2: 0000000000000000000000000000000000800000000000000022600000000000
[+] Thread 0: 0000000000000000000000000000000000800000000000000022500000000000
[+] Thread 3: 0000000000000000000000000000000000800000000000000022700000000000
Total 70368744177664 keys in 30 seconds: 2345624805922 keys/s
[+] Thread 2: 0000000000000000000000000000000000800000000000000022800000000000
[+] Thread 1: 0000000000000000000000000000000000800000000000000022900000000000
[+] Thread 0: 0000000000000000000000000000000000800000000000000022a00000000000
[+] Thread 3: 0000000000000000000000000000000000800000000000000022b00000000000
Total 140737488355328 keys in 60 seconds: 2345624805922 keys/s
[+] Thread 2: 0000000000000000000000000000000000800000000000000022c00000000000
[+] Thread 1: 0000000000000000000000000000000000800000000000000022d00000000000
[+] Thread 0: 0000000000000000000000000000000000800000000000000022e00000000000
Total 211106232532992 keys in 90 seconds: 2345624805922 keys/s
Total 263882790666240 keys in 120 seconds: 2199023255552 keys/s
Total 263882790666240 keys in 150 seconds: 1759218604441 keys/s
Total 263882790666240 keys in 180 seconds: 1466015503701 keys/s
Total 263882790666240 keys in 210 seconds: 1256584717458 keys/s
Total 263882790666240 keys in 240 seconds: 1099511627776 keys/s
Total 263882790666240 keys in 270 seconds: 977343669134 keys/s
Total 263882790666240 keys in 300 seconds: 879609302220 keys/s
Keep working... 

Hello @albertobsd, thank you for your software. It would be nice to see progress bar for initial load. Right now, I'm using k*bsgb mode with -k 1600, and it's running for an hour without starting or showing errors. My free system memory is equal to 6% all this time. I'm thinking, it's doing something in pre-allocated memory. But still it's only my predictions. The last thing displayed is: [+] precalculating 67... bP points

Hi Alberto,

Is it possible to use the rmd160 mode to hunt for SegWit(Bech32) addresses (example: bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4)? This will probably hurt a lot the speed of the script?
What about hunting P2SH addresses like SegWit(nested) (example: 3DwYUKCDoU8hdBgpGkNy8QXjUV6qTb6yp1) or P2WSH addresses (example: bc1qgdjqv0av3q56jvd82tkdjpy7gdp9ut8tlqmgrpmv24sq90ecnvqqjwvw97)? I think it is not possible since the steps involved are differents than P2PKH or SegWit(Bech32) invoice adresses.

Thanks!

Hi there,

Awesome project you've developped! Really loving it.
More of a question not an issue because I simply lack the technical knowledge.
Would your BSGS algorithm be applicable to mining software and maybe achieve the same kind of performance of x petahashes/s?
To my knowledge i've never seen petahashes/s on even high end ASIC mining gear. (except when combined) Imagine mining with the performance of BSGS even on low-end hardware wouldn't that drastically increase the blockchain network's performance worldwide for the same amount of power used?

Just a thought, I'd love to read thoughts on this as well thanks!

Dear Alberto!

Smth strange goes on when i'm trying to run this code.

I run this code and nothing happens, no speed per second, no new range displayed.... But the CPU utilization is good (3 threads are used on 100%).
But if I run smth like searching 64th or 120th puzzle everything goes well.
Why this can occur?

Hi Alberto,

First of all great job for the tool!

I have several questions for you if you don't mind:

1. Is it possible to put an example in the README.md on how to use the XPOINT mode with choosing a scan across all the keyspace range?
2. I saw that @iceland2k14 is also using the BSGS algo to search for multiple pubkeys together. Is his tool corresponding to what you call XPOINT mode?
3. What is the best option in term of speed with using CPU and RAM: the RMD160 or the XPOINT mode? I think it should be the XPOINT mode if it uses the BSGS algo which is RAM dependant. The RMD160 is more suited for GPU use.
4. Is the XPOINT mode currently only compatible with the X value and not with the compressed/uncompressed ECDSA pubkeys?
5. The most important question: Do you know a script or a database to get the X value or the compressed/uncompressed ECDSA pubkeys from dormant addresses with positive BTC balance? I think it should be a good idea to make such database that can be use with keyhunt :) I have seen the tool from @graymauser but I don't think it retrieve the ECDSA pubkeys.
6. What do you think about this tool as compared to the RMD160 or the XPOINT mode

Thanks!

i have generated random 20 mln adresses bsgs in range 800000000000000000000000000000:FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF.
load it to keyhunt.
run cammand ./keyhunt -m bsgs -f random_pubs.txt -r 800000000000000000000000000000:FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF -s 60 -R

and its stuck here :
[+] Version 0.1.20210112 BSGS
[+] Setting mode BSGS
[+] Stats output every 60 seconds
[+] Setting random mode.
[+] Opening file random_pubs.txt
[+] Added 19999999 points from file
[+] Setting N up to 17592186044416.
[+] Init bloom filter for 4194304 elements : 7.00 MB
[+] Allocating 128.00 MB for aMP Points
[+] Precalculating 4194304 aMP points
[+] Allocating 160.00 MB for bP Points
[+] precalculating 4194304 bP points
[+] Sorting 4194304 elements
[+] Thread 0: 0000000000000000000000000000000000ec842d5ee3e39c0f384e482569bc7f > running 1 hour no update

why: i want to test if it can load large file and wanna test randomnes

Hi
if i add -b XXX or -r XXXX......:XXXX....... key hunter will start from first Bit , the intervale work correctly only in random mode -R
just reporting the bug

thank you

Hi,

Instead of running one process like

sudo ./keyhunt -m bsgs -f  tests/120.txt   -t 4 -k 1024 -q -R

Can we run 4 parallel process like this?
sudo ./keyhunt -m bsgs -f tests/120A.txt -t 1 -k 256 -q -R
sudo ./keyhunt -m bsgs -f tests/120B.txt -t 1 -k 256 -q -R
sudo ./keyhunt -m bsgs -f tests/120C.txt -t 1 -k 256 -q -R
sudo ./keyhunt -m bsgs -f tests/120D.txt -t 1 -k 256 -q -R

Because processing 1761607680 bP points for -k 1024 takes a very very very very very long time. :)

Please advise

Thank you
Regards

--

Hey guys, I would like to use the fastest method ( BSGS) but I can't find a way to convert a list of Bitcoin addresses to PubKey ( compressed or uncompressed), can you guys give a me a little help?
Thank you!

Thank you for the codes in c especially. Somehow I managed to build it on Windows 10 but there is one problem: Ram usage increased during the program run, and eventually after few minutes my whole 16GB got eaten and the computer froze. Maybe this is caused by the platform change or maybe some memory re-allocation issue.
Is there anyone who is facing the same problem?

hello, sorry to bother you. i get this error when to build

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
keyhunt.c: In function ‘int main(int, char**)’:
keyhunt.c:668:47: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 3 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Wformat=]
668 | fprintf(stderr,"[E] error bloom_init for %u elements.\n",N);
| ~^ ~
| | |
| unsigned int uint64_t {aka long unsigned int}
| %lu
/usr/bin/ld: cannot find -lgmp
collect2: error: ld returned 1 exit status
make: *** [Makefile:15: default] Error 1

g++ -m64 -mssse3 -Wno-unused-result -Wno-write-strings -O2 -c secp256k1/Int.cpp -o Int.o
g++: error: unrecognized command line option ‘-m64’
g++: error: unrecognized command line option ‘-mssse3’
make: *** [Makefile:9: default] Error 1

Hello,

When I run the program in -m rmd160 mode, with the -R flag, the base key is not in the desired range :

Without the -R flag, is working normal

Hello @albertobsd ,
Can we use this public key (66 Characters) in bsgs mode?
This key was extracted using crackbtc.
0313c402e03becbcc93e93fadd8eb9d1b04c7479bfc0864fff6c49a5ca233b6f2f

Thank you
Regards

Since #43 GMP leftover in these two files can be deprecated I think.

the new secp256k1 is not compiling in termix

sorry guys i will work in that.

Hello @albertobsd . Is it possible to compile the release for Windows?Tnx...kanhavishva version for windows has a very low speed.And do not have a parameter - bsgs.Speed 8 threads

hi
excelent work

i just want ask it's a multi key search simultaneously or it will search by order in the list one by one??

thank you

For some reason, the program does not see the bPfile.bin, although it is located in the same folder as the keyhunt.exe.

Hello Alberto! First of all, I want to thank you for this wonderful program! Yes, of course GPU implementation are lacking, but even so, it works just fine. A question. Is it possible to specify the range for generating points when creating a bPfile yourself? Or does the generation always start from one and up to the value specified at startup? Thanks.

Hello, thank you very much for your software, I am trying to run it correctly but I don't know if I am doing it right because the speed I see I think is very low, I am using an inter core i3 900F,

I waited, about 3 hours there is no reaction, I think it does not work normally!!!!!

./keyhunt -t 24 -r 1:fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 -m bsgs -f pubadd.txt -k 800050 -R -n 655360000 -s 1 -q [+] Version 0.1.20210412 secp256k1 [+] Setting 24 threads [+] Setting mode BSGS [+] Setting k factor to 800050 [+] Setting random mode. [+] Stats output every 1 seconds [+] Set quiet thread output [+] Opening file pubadd.txt [+] Added 22 points from file [+] Setting N up to 0. [+] Init 1st bloom filter for 20481280000 elements : 70207.00 MB [+] Init 2nd bloom filter for 1024064000 elements : 3510.37 MB [+] Allocating 0.0 MB for 0 aMP Points [+] Precalculating 0 aMP points [+] Allocating 15625.98 MB for 1024064000 bP Points [+] processing 20481269760/20481280000 bP points^C 99%[[C0/20481280000 bP points : 99%

I can not understand. what type of file to use in xpoint mode
i have hex private key FF8B8141D7A67C073318BE7960981626FEE0809AF1CB4E97876DDACC6007D80A
I get from him

Uncompressed Address 
Base58 encoding: 1M41L7pWnoEnsxkcVLiWs5PXpbqVHZJ3Ze
RIPEMD-160 hash: 00DBF409E8C8DC9AB5277C55F3CD10D9663211498D166A9155
Compressed Address
Base58 encoding: 1KNbaPVP9z2V5eGapVXSN54oNSWXECpTjx
RIPEMD-160 hash: 00C987DC922B8705D066E9EB63F4C1838D84F35357652A8C8B

when i use -m address and in the file addresses.txt i have Base58 encoding i get HIT!!

./keyhunt -r FF8B8141D7A67C073318BE7960981626FEE0809AF1CB4E97876DDACC6007D80A
[+] Setting search for btc adddress
[+] Allocating memory for 2 elements
[+] Initializing bloom filter for 2 elements.
[+] Loading data to the bloomfilter
[+] Bloomfilter completed
[+] Sorting data
[+] 2 values were loaded and sorted
Thread 0 : Setting up base key: ff8b8141d7a67c073318be7960981626fee0809af1cb4e97876ddacc6007d80a
HIT!! PrivKey: ff8b8141d7a67c073318be7960981626fee0809af1cb4e97876ddacc6007d80a
pubkey: 023b903e6ca8accbb693243b5caf83be5cb0a484919a12cdf403b526fc7c9eba89
address: 1KNbaPVP9z2V5eGapVXSN54oNSWXECpTjx
HIT!! PrivKey: ff8b8141d7a67c073318be7960981626fee0809af1cb4e97876ddacc6007d80a
pubkey: 043b903e6ca8accbb693243b5caf83be5cb0a484919a12cdf403b526fc7c9eba89836555c0f7e298862bbb25dc49f54292e315b0b27da47ab19c7f9bf0dae66500
address: 1M41L7pWnoEnsxkcVLiWs5PXpbqVHZJ3Ze

but when i use -m xpoint and in file addresses.txt i have RIPEMD-160 hash i get this:

./keyhunt -r FF8B8141D7A67C073318BE7960981626FEE0809AF1CB4E97876DDACC6007D80A -m xpoint
[+] Setting mode xpoint
[+] Allocating memory for 2 elements
[+] Initializing bloom filter for 2 elements.
[+] Loading data to the bloomfilter
[+] Bloomfilter completed
[+] Sorting data
[+] 2 values were loaded and sorted
Thread 0 : Setting up base key: ff8b8141d7a67c073318be7960981626fee0809af1cb4e97876ddacc6007d80a
Total 5242880 keys in 30 secods: 174762 keys/s

i don't get matches, what i am doing wrong

Really weird:

./keyhunt -m bsgs -f tests/substracted40.txt -n 65536 -t 4 -r 8000000000
[+] Version 0.1.20210330a
[+] Setting mode BSGS
[+] Setting 4 threads
[+] Opening file tests/substracted40.txt
[+] Added 6003 points from file
[+] Setting N up to 65536.
[+] Init 1st bloom filter for 256 elements : 0.00 MB
[+] Init 2nd bloom filter for 13 elements : 0.00 MB
[+] Allocating 0.0 MB for 256 aMP Points
[+] Precalculating 256 aMP points
double free or corruption (out)

if you have a work computer, it is recommended to use only 80% of the RAM.
All settings are specified for a working computer!
bPfile must be a multiple of 32 (Gb memory * 134217728)
Create a file for 2 GB memory with a dual core processor: ./bPfile 268435456 ./bPfile.bin -t 2
P .S: On Windows, use PowerShell.

dear developers, please check my numbers and if they are correct it may be worth adding them to the description for other people to understand.

+-----------------------------------------------------------------+
|   Gb memory | - k     | bPfile  (134217728 * gb)  | Size gb HDD |
+------------ | --------| --------------------------| ------------+
 | 2          | 64      | 268435456                 | 8,192       |
| 4           | 128     | 536870912                 |             |
| 8           | 256     | 1073741824                |             |
| 16          | 512     | 2147483648                |             |
| 24          | 768     | 3221225472                |             |
| 32          | 1024    | 4294967296                |             |
| 64          | 2048    | 8589934592                |             |
+-------------+---------+---------------------------+-------------+

the new secp256k1 is not compiling in termux

sorry guys i will work in that.

Hi
what are the warnings bro?
keyhunt.c: In function ‘int main(int, char**)’: keyhunt.c:668:47: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 3 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Wformat=] 668 | fprintf(stderr,"[E] error bloom_init for %u elements.\n",N); | ~^ ~ | | | | unsigned int uint64_t {aka long unsigned int} | %lu

As most of all i interact with Alberto's repository, i decided to publish this issue here.
Does anyone know what kind of searching is better mathematically? Continuously or random?
For example in the hypothetical range of 0...100 with can forcibly search diving range on 2. I.e. from 0 to 1, then from 99 to 100; Next from 50 to 51. Then from 24 to 25 and from 74 to 75... etc..
Or we can simply run random mode and wait for results.
What is better particularly from mathematical point of view?

Help me install. Make error:~/keyhunt$ 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
In file included from secp256k1/Int.cpp:18:0:
secp256k1/Int.cpp: In member function ‘void Int::Sub(Int*)’:
secp256k1/Int.h:222:88: error: ‘__builtin_ia32_sbb_u64’ was not declared in this scope
#define _subborrow_u64(a,b,c,d) __builtin_ia32_sbb_u64(a,b,c,(long long unsigned int*)d);
^
secp256k1/Int.cpp:343:7: note: in expansion of macro ‘_subborrow_u64’
c = _subborrow_u64(c, bits64[0], a->bits64[0], bits64 +0);
^
secp256k1/Int.cpp: In member function ‘void Int::Sub(Int*, Int*)’:
secp256k1/Int.h:222:88: error: ‘__builtin_ia32_sbb_u64’ was not declared in this scope
#define _subborrow_u64(a,b,c,d) __builtin_ia32_sbb_u64(a,b,c,(long long unsigned int*)d);
^
secp256k1/Int.cpp:362:7: note: in expansion of macro ‘_subborrow_u64’
c = _subborrow_u64(c, a->bits64[0], b->bits64[0], bits64 + 0);
^
secp256k1/Int.cpp: In member function ‘void Int::Sub(uint64_t)’:
secp256k1/Int.h:222:88: error: ‘__builtin_ia32_sbb_u64’ was not declared in this scope
#define _subborrow_u64(a,b,c,d) __builtin_ia32_sbb_u64(a,b,c,(long long unsigned int*)d);
^
secp256k1/Int.cpp:379:7: note: in expansion of macro ‘_subborrow_u64’
c = _subborrow_u64(c, bits64[0], a, bits64 + 0);
^
secp256k1/Int.cpp: In member function ‘void Int::SubOne()’:
secp256k1/Int.h:222:88: error: ‘__builtin_ia32_sbb_u64’ was not declared in this scope
#define _subborrow_u64(a,b,c,d) __builtin_ia32_sbb_u64(a,b,c,(long long unsigned int*)d);
^
secp256k1/Int.cpp:396:7: note: in expansion of macro ‘_subborrow_u64’
c = _subborrow_u64(c, bits64[0], 1, bits64 + 0);
^
secp256k1/Int.cpp: In member function ‘void Int::Neg()’:
secp256k1/Int.h:222:88: error: ‘__builtin_ia32_sbb_u64’ was not declared in this scope
#define _subborrow_u64(a,b,c,d) __builtin_ia32_sbb_u64(a,b,c,(long long unsigned int*)d);
^
secp256k1/Int.cpp:448:6: note: in expansion of macro ‘_subborrow_u64’
c = _subborrow_u64(c, 0, bits64[0], bits64 + 0);
^
Makefile:2: recipe for target 'default' failed
make: *** [default] Error 1

Hello,
Q1
We extract cKey, Public Key and Public address using your other program crackBTCwallet command get_mkey_ckey.
Can we use the extracted public key 0113c403exxxecbcb83e93xxxxxxxxx1b04d9479bfc0864ef46c49a6caxxxb6f1f as input for bsgs scenario in key hunt?

Q2
-r range is not working
I input -r 800000000000000000000000000000:900000000000000000000000000000
where as the program shows
[+] Min range: 800000000000000000000000000000
[+] Max range: ffffffffffffffffffffffffffffff

Thank you and please advise

hi
when i use ex; ( -l compress ) in the bigining it will show will search for uncompressed only and inverse if i use -l uncompress
just text error or inversed setting?

can we Faster this code With Gpu

hi. I just can't understand what are the chances in pub2rmd mode finding the public key? this is more than a puzzle 120?
it seems to me better to run with a key -R.

Why can't you use -r and -R together?
it would be effective and interesting for experiments

the mode works permanently randomly or as in bitcrack.

What do I have to write to the txt file to solve 120 puzzles?

I saved it in my file like this.
Did I add it correctly?

04ceb6cbbcdbdf5ef7150682150f4ce2c6f4807b349827dcdbdd1f2efa885a26302b195386bea3f5f002dc033b92cfc2c9e71b586302b09cfe535e1ff290b1b5ac # Compressed Address : 17s2b9ksz5y7abUm92cHwG8jEPCzK3dLnT

after editing the Makefile, the build was successful.
thanks for the windows version.
but the assembly behaves strangely at work.

1. run (./keyhunt -m rmd160 -f tests / 1to32.rmd -r 1: FFFFFFFF -l compress)
2. the program finds 22 addresses and stops.
3. run (./keyhunt -m rmd160 -f tests / 64.rmd -b 64 -l compress -R)
4. the program does not display anything, exits
5. this behavior in all modes (address, rmd160)

keyhunt.c: In function ‘main’: keyhunt.c:1025:45: warning: format ‘%i’ expects argument of type ‘int’, but argument 3 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Wformat=] 1025 | fprintf(stderr,"[E] error bloom_init [%i]\n",i); | ~^ ~ | | | | int uint64_t {aka long unsigned int} | %li keyhunt.c:1031:63: warning: format ‘%i’ expects argument of type ‘int’, but argument 3 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Wformat=] 1031 | fprintf(stderr,"[E] error bloom_init for 1000 elements [%i]\n",i); | ~^ ~ | | | | int uint64_t {aka long unsigned int} | %li keyhunt.c:1062:41: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘long unsigned int’ [-Wformat=] 1062 | printf("[+] Allocating %.1f MB for %llu aMP Points\n",(float)(((uint64_t)(bsgs_auxsizeof(struct Point)))/(uint64_t)1048576),bsgs_aux); | ~~~^ ~~~~~~~~ | | | | long long unsigned int long unsigned int | %lu keyhunt.c:1138:41: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Wformat=] 1138 | printf("[+] Allocating %.2f MB for %llu bP Points\n",(float)((uint64_t)((uint64_t)bsgs_m2(uint64_t)sizeof(struct bsgs_xvalue))/(uint64_t)1048576),bsgs_m2); | ~~~^ ~~~~~~~ | | | | long long unsigned int uint64_t {aka long unsigned int} | %lu keyhunt.c: In function ‘thread_process_bsgs’: keyhunt.c:2227:35: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘long unsigned int’ [-Wformat=] 2227 | if(FLAGDEBUG ) printf("%u of %llu\n",bloom_counter,(uint64_t)(bsgs_auxbsgs_point_number)); | ~~~^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | | | long unsigned int | long long unsigned int | %lu keyhunt.c: In function ‘thread_process_bsgs_random’: keyhunt.c:2374:35: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘long unsigned int’ [-Wformat=] 2374 | if(FLAGDEBUG ) printf("%u of %llu\n",bloom_counter,(uint64_t)(bsgs_auxbsgs_point_number)); | ~~~^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | | | long unsigned int | long long unsigned int | %lu

format ‘%f’ expects argument of type ‘double’, but argument 3 has type ‘uint32_t {aka unsigned int}’ [-Wformat=]
printf("[+] Allocating memory for %u elements ?????

Hi Alberto,

I have made a file "40_xpoints.txt" with 1000000 values of the puzzle 40.
After running the xpoint mode with this command: ./keyhunt -m xpoint -f 40_xpoints.txt -n 65536 -t 8 -b 40 -q -R
I get a strange output for the pubkeys on the screen and in KEYFOUNDKEYFOUND.txt.

PrivKey: 6afe8390d6
pubkey: 303237373430313264653064656231376535643837363333303461623039366463
PrivKey: 75ea480456
pubkey: 303262326534306438646334386535303533356432313535346161323666653839
PrivKey: 79e7570856
pubkey: 303336373332653635636336386438323236303832366238323337646135646433
PrivKey: 781bac6bd6
pubkey: 303264336632393866343966663763373766646239363466633466343966396430
PrivKey: 7587523a56
pubkey: 303338633166363239343461383263313730643462303865616432633166386664
PrivKey: 7f2052e956
pubkey: 303361323236396137643365333536636337633762353266316266326566336638
...

Hi everyone, some user report this decrement of speed with K = 1450

Version 0.1.20210322  Total 5283603588684185600 keys in 600 seconds: 8 806 005 981 140 309 keys/s
Version 0.1.20210330  Total 3282812546108620800 keys in 600 seconds: 5 471 354 243 514 368 keys/s

I do similar test with K = 128 without any difference but i will rerun that test again with a bigger K

Anyone have that issue too?

Some core computation functions like sha256, bloom (and some others maybe) are implemented as per standards.

To gain more computation speed, SIMD instructions accelerated implementations of these functions could help. For instance, we know a SIMD accelerated version of sha256 is used by the bitcoin-core client. And for reference, some accelerated versions like sha256-simd have obtained up to 8x improvement compared to a standard implementation.

We Need to Go Deeper.