Keyhunt - development requests - bug reports

[arulbero]

Just to clarify, is the filter precomputed?

Yes, precomputed bloom filter, same as original keyhunt but Slait version has a few enhancements.

How much time it takes to find a #75 key ? Only few seconds?

Yes, only a few seconds as you can see in the .gif

Here is scanning some ranges, about 200 seconds for each subrange of 76 bits.

Code:

❯ ./keyhunt -m bsgs -f 135.txt -D deep.txt -n 0x1000000000000 -k 16384 -t 192 -q -s 1 -S
[+] Version 1.0.4.20260113 Slait Edition, developed by AlbertoBSD
[+] K factor 16384
[+] Threads : 192
[+] Quiet thread output
[+] Stats output every 1 seconds
[+] Mode BSGS sequential
[+] Loaded 13 ranges from deep.txt
[+] Opening file 135.txt
[+] Added 1 points from file
[+] Range
[+] -- from : 0x5851eb8551eb8550000000000000000000
[+] -- to   : 0x5851eb8551eb855fffffffffffffffffff
[+] N = 0x1000000000000
[+] Bloom filter for 274877906944 elements : 942249.56 MB
[+] Bloom filter for 8589934592 elements : 29445.30 MB
[+] Bloom filter for 268435456 elements : 920.17 MB
[+] Allocating 4096.00 MB for 268435456 bP Points
[+] Reading bloom filter from file filters/bloom/k16384n0x1000000000000/keyhunt_bsgs_1_274877906944.blm (headers) Done!
[+] Reading bloom filter from file filters/bloom/k16384n0x1000000000000/keyhunt_bsgs_2_8589934592.blm (headers) Done!
[+] Reading bP Table from file filters/bloom/k16384n0x1000000000000/keyhunt_bsgs_4_268435456.tbl .[+] Reading bloom filter from file filters/bloom/k16384n0x1000000000000/keyhunt_bsgs_3_268435456.blm (headers) Done!
[+] Time reading the filter: 4 min 42 sec


[+] Range 1/13
[+] -- from:0x5851eb8551eb8550000000000000000000
[+] -- to  :0x5851eb8551eb855fffffffffffffffffff
[+] [][200 sec][~377 Ekeys/s (377789318629571617095 keys/s)]
[+] Range 2/13
[+] -- from:0x5851eb8551eb8560000000000000000000
[+] -- to  :0x5851eb8551eb856fffffffffffffffffff
[+] [][200 sec][~377 Ekeys/s (377789318629571617095 keys/s)]
[+] Range 3/13
[+] -- from:0x5851eb8551eb8570000000000000000000
[+] -- to  :0x5851eb8551eb857fffffffffffffffffff
[+] [][200 sec][~377 Ekeys/s (377789318629571617095 keys/s)]
[+] Range 4/13
[+] -- from:0x5851eb8551eb8580000000000000000000
[+] -- to  :0x5851eb8551eb858fffffffffffffffffff
[+] [][200 sec][~377 Ekeys/s (377789318629571617095 keys/s

It will take billions of  years to search like this and find the puzzle 135 key.  

Then 4:32 is only the time to read?

By the way, I'm working on a Kangaroo program, that split the work: precomputed a large work (tame) so I can retrieve a key with the wild in a short time.

For example, on my laptop (Alder Lake 12700H) with 260M DP (precomputed) in the database, it takes basically 1 second to retrieve a key in range [2^71,2^72]

[oddstake]

Then 4:32 is only the time to read?

4:32 is the time to read from disk AND fill 1T of RAM

By the way, I'm working on a Kangaroo program, that split the work: precomputed a large work (tame) so I can retrieve a key with the wild in a short time.

For example, on my laptop (Alder Lake 12700H) with a 260M di DP in the database, it takes basically 1 second to retrieve a key in range [2^71,2^72]

I tried RCKangaroo, it works fine. It can find puzzle 85 key in about 30 sec on my GPU.

Code:

time ./rckangaroo -dp 18 -range 84 -start 1000000000000000000000 -pubkey 0329c4574a4fd8c810b7e42a4b398882b381bcd85e40c6883712912d167c83e73a -tames /home/ubuntu/tames/tames8
4.dat
********************************************************************************
*                    RCKangaroo v3.0  (c) 2024 RetiredCoder                    *
********************************************************************************

This software is free and open-source: https://github.com/RetiredC
It demonstrates fast GPU implementation of SOTA Kangaroo method for solving ECDLP
Linux version
CUDA devices: 1, CUDA driver/runtime: 13.1/12.9
GPU 0: NVIDIA GeForce RTX 4080, 15.99 GB, 76 CUs, cap 8.9, PCI 1, L2 size: 65536 KB
Total GPUs for work: 1

MAIN MODE

Solving public key
X: 29C4574A4FD8C810B7E42A4B398882B381BCD85E40C6883712912D167C83E73A
Y: 0E02C3AFD79913AB0961C95F12498F36A72FFA35C93AF27CEE30010FA6B51C53
Offset: 0000000000000000000000000000000000000000001000000000000000000000

Solving point: Range 84 bits, DP 18, start...
SOTA method, estimated ops: 2^42.202, RAM for DPs: 0.906 GB. DP and GPU overheads not included!
Estimated DPs per kangaroo: 41.319.
load tames...
tames loaded
GPU 0: allocated 1426 MB, 466944 kangaroos. OldGpuMode: No
GPUs started...
MAIN: Speed: 5082 MKeys/s, Err: 0, DPs: 193023K/19293K, Time: 0d:00h:00m/0d:00h:16m
MAIN: Speed: 5075 MKeys/s, Err: 0, DPs: 193214K/19293K, Time: 0d:00h:00m/0d:00h:16m
Stopping work ...
Point solved, K: 0.026 (with DP and GPU overheads)


PRIVATE KEY: 00000000000000000000000000000000000000000011720C4F018D51B8CEBBA8


real    0m33.613s
user    0m6.865s
sys     0m27.054s

[arulbero]

Then 4:32 is only the time to read?

4:32 is the time to read from disk AND fill 1T of RAM

By the way, I'm working on a Kangaroo program, that split the work: precomputed a large work (tame) so I can retrieve a key with the wild in a short time.

For example, on my laptop (Alder Lake 12700H) with a 260M di DP in the database, it takes basically 1 second to retrieve a key in range [2^71,2^72]

I tried RCKangaroo, it works fine. It can find puzzle 85 key in about 30 sec on my GPU.

Code:

time ./rckangaroo -dp 18 -range 84 -start 1000000000000000000000 -pubkey 0329c4574a4fd8c810b7e42a4b398882b381bcd85e40c6883712912d167c83e73a -tames /home/ubuntu/tames/tames8
4.dat
********************************************************************************
*                    RCKangaroo v3.0  (c) 2024 RetiredCoder                    *
********************************************************************************

This software is free and open-source: https://github.com/RetiredC
It demonstrates fast GPU implementation of SOTA Kangaroo method for solving ECDLP
Linux version
CUDA devices: 1, CUDA driver/runtime: 13.1/12.9
GPU 0: NVIDIA GeForce RTX 4080, 15.99 GB, 76 CUs, cap 8.9, PCI 1, L2 size: 65536 KB
Total GPUs for work: 1

MAIN MODE

Solving public key
X: 29C4574A4FD8C810B7E42A4B398882B381BCD85E40C6883712912D167C83E73A
Y: 0E02C3AFD79913AB0961C95F12498F36A72FFA35C93AF27CEE30010FA6B51C53
Offset: 0000000000000000000000000000000000000000001000000000000000000000

Solving point: Range 84 bits, DP 18, start...
SOTA method, estimated ops: 2^42.202, RAM for DPs: 0.906 GB. DP and GPU overheads not included!
Estimated DPs per kangaroo: 41.319.
load tames...
tames loaded
GPU 0: allocated 1426 MB, 466944 kangaroos. OldGpuMode: No
GPUs started...
MAIN: Speed: 5082 MKeys/s, Err: 0, DPs: 193023K/19293K, Time: 0d:00h:00m/0d:00h:16m
MAIN: Speed: 5075 MKeys/s, Err: 0, DPs: 193214K/19293K, Time: 0d:00h:00m/0d:00h:16m
Stopping work ...
Point solved, K: 0.026 (with DP and GPU overheads)


PRIVATE KEY: 00000000000000000000000000000000000000000011720C4F018D51B8CEBBA8


real    0m33.613s
user    0m6.865s
sys     0m27.054s

Of course, I want to underline only that, if the goal is only to retrieve as fast as possible a key in a short range like 2^75 o 2^80, it is possible using only a cpu.

[ibbonmailru]

Ive got another error. What that mean? And what to do?

https://dropmefiles.com/ezIQj

[oddstake]

Ive got another error. What that mean? And what to do?

https://dropmefiles.com/ezIQj

Maybe not enough RAM/SSD/SWAP

[ibbonmailru]

Ive got another error. What that mean? And what to do?

https://dropmefiles.com/ezIQj

Maybe not enough RAM/SSD/SWAP

More than...
https://dropmefiles.com/dRCUM

[SlaitX]

Ive got another error. What that mean? And what to do?

https://dropmefiles.com/ezIQj

Maybe not enough RAM/SSD/SWAP

More than...
https://dropmefiles.com/dRCUM

1. Check your hard drive space; it should be more than ~300GB (~200GB source + ~100GB fuse filter)
2. Increase the swap file by at least 80GB, or better yet, 120GB
After that, the problem will go away
You've already lost 256 out of 54 packets, which means you've lost ~1/5 of your original file.

[oddstake]

1. Check your hard drive space; it should be more than ~300GB (~200GB source + ~100GB fuse filter)
2. Increase the swap file by at least 80GB, or better yet, 120GB
After that, the problem will go away
You've already lost 256 out of 54 packets, which means you've lost ~1/5 of your original file.

How much swap space should I  have to generate fuse tables to fill 1T of RAM ?
I tried a few lower values from your table but if using more than -k 16384  and -n 0x400000000000  it simply fill all the available 1T RAM and also 2T of swap space and then the program quit because swap is not enough.
-x bloom works correctly but -x fuse it is not clear how much swap / ssd space should I have.

[SlaitX]

1. Check your hard drive space; it should be more than ~300GB (~200GB source + ~100GB fuse filter)
2. Increase the swap file by at least 80GB, or better yet, 120GB
After that, the problem will go away
You've already lost 256 out of 54 packets, which means you've lost ~1/5 of your original file.

How much swap space should I  have to generate fuse tables to fill 1T of RAM ?
I tried a few lower values from your table but if using more than -k 16384  and -n 0x400000000000  it simply fill all the available 1T RAM and also 2T of swap space and then the program quit because swap is not enough.
-x bloom works correctly but -x fuse it is not clear how much swap / ssd space should I have.

I recommend Linux.
1 TB RAM, 1 TB swap, ~4 TB hard drive (1 TB swap + 3 TB source data)
Ready fuse filter ~750 GB

For an approximate calculation, run
./keyhunt -m bsgs -f 135.txt -D deep.txt -n 0x1000000000000 -k 4096 -n 0x400000000000 -t 192 -s 1 -S
During the build, check how much RAM is used and the size of the filters/tmp folder. Multiply the resulting values ​​by 4 to get the correct values.

[oddstake]

I recommend Linux.
1 TB RAM, 1 TB swap, ~4 TB hard drive (1 TB swap + 3 TB source data)
Ready fuse filter ~750 GB

For an approximate calculation, run
./keyhunt -m bsgs -f 135.txt -D deep.txt -n 0x1000000000000 -k 4096 -n 0x400000000000 -t 192 -s 1 -S
During the build, check how much RAM is used and the size of the filters/tmp folder. Multiply the resulting values ​​by 4 to get the correct values.

It's not working, already tried even with 2T swap , the programs fills 1T of RAM then fills all 2T of swap and then because not having enough swap , it quits.
If the values are lower than  -k 16384  and -n 0x400000000000 it works fine, if the values are higher then it won't work. It needs more swap.
I will check the size of /tmp folder to get the correct values.

[SlaitX]

I recommend Linux.
1 TB RAM, 1 TB swap, ~4 TB hard drive (1 TB swap + 3 TB source data)
Ready fuse filter ~750 GB

For an approximate calculation, run
./keyhunt -m bsgs -f 135.txt -D deep.txt -n 0x1000000000000 -k 4096 -n 0x400000000000 -t 192 -s 1 -S
During the build, check how much RAM is used and the size of the filters/tmp folder. Multiply the resulting values ​​by 4 to get the correct values.

It's not working, already tried even with 2T swap , the programs fills 1T of RAM then fills all 2T of swap and then because not having enough swap , it quits.
If the values are lower than  -k 16384  and -n 0x400000000000 it works fine, if the values are higher then it won't work. It needs more swap.
I will check the size of /tmp folder to get the correct values.

Yes, you're right. A larger swap file is needed because the FUSE filter needs to hold all the raw data (the tmp folder) in memory + 1/256 to form one batch.

[oddstake]

Yes, you're right. A larger swap file is needed because the FUSE filter needs to hold all the raw data (the tmp folder) in memory + 1/256 to form one batch.

Anything above -k 16384 and -n 0x400000000000 is impossible for -x fuse. You need more than 10T RAM/SWAP and also lots of T for raw data.
It works for -x bloom indeed, better than Alberto's version, almost double the speed.

[sergeykubrik]

Why can keyhunt search in a different range when searching in a certain range?

[oddstake]

@SlaitX , In BSGS mode, when I use your version with -R, the speed drops to half compared to the normal sequential run without -R. I tried Alberto’s original version and, in his case, the speed is the same with or without -R. It’s probably a bug in your app or maybe you didn't write your code specific for -R. Are you planning to release an update to the program in the future? Thanks.

[SlaitX]

@SlaitX , In BSGS mode, when I use your version with -R, the speed drops to half compared to the normal sequential run without -R. I tried Alberto’s original version and, in his case, the speed is the same with or without -R. It’s probably a bug in your app or maybe you didn't write your code specific for -R. Are you planning to release an update to the program in the future? Thanks.

Updated version. https://github.com/Slait/Keyhuntbsgs/releases/tag/1.0.6.20260306

Examples of running the command correctly:
keyhunt.exe -m bsgs -f test.txt -r 80a15e21125e3806:96e15e21125e3806 -k 128 -S -s 1 -x fuse -t 16 -B sequential
keyhunt.exe -m bsgs -f test.txt -r 80a15e21125e3806:96e15e21125e3806 -k 128 -S -s 1 -x fuse -t 16 -B backward
keyhunt.exe -m bsgs -f test.txt -r 80a15e21125e3806:96e15e21125e3806 -k 128 -S -s 1 -x fuse -t 16 -B both
keyhunt.exe -m bsgs -f test.txt -r 80a15e21125e3806:96e15e21125e3806 -k 128 -S -s 1 -x fuse -t 16 -B random
keyhunt.exe -m bsgs -f test.txt -r 80a15e21125e3806:96e15e21125e3806 -k 128 -S -s 1 -x fuse -t 16 -B dance

[MBuran]

Updated version. https://github.com/Slait/Keyhuntbsgs/releases/tag/1.0.6.20260306

Examples of running the command correctly:
keyhunt.exe -m bsgs -f test.txt -r 80a15e21125e3806:96e15e21125e3806 -k 128 -S -s 1 -x fuse -t 16 -B sequential
keyhunt.exe -m bsgs -f test.txt -r 80a15e21125e3806:96e15e21125e3806 -k 128 -S -s 1 -x fuse -t 16 -B backward
keyhunt.exe -m bsgs -f test.txt -r 80a15e21125e3806:96e15e21125e3806 -k 128 -S -s 1 -x fuse -t 16 -B both
keyhunt.exe -m bsgs -f test.txt -r 80a15e21125e3806:96e15e21125e3806 -k 128 -S -s 1 -x fuse -t 16 -B random
keyhunt.exe -m bsgs -f test.txt -r 80a15e21125e3806:96e15e21125e3806 -k 128 -S -s 1 -x fuse -t 16 -B dance

Can you compile to ubuntu 22 as last time? Or (prefer) with new glibc 2.39? I can't properly install 2.38 on my Ubuntu 22.04.5
Ubuntu 24.04.4 -> Illegal instruction (core dumped) - glibc 2.39 

[SlaitX]

Can you compile to ubuntu 22 as last time? Or (prefer) with new glibc 2.39? I can't properly install 2.38 on my Ubuntu 22.04.5
Ubuntu 24.04.4 -> Illegal instruction (core dumped) - glibc 2.39 

Upload Ubuntu 22 Version
https://github.com/Slait/Keyhuntbsgs/releases/tag/1.0.6.20260306

[MBuran]

Upload Ubuntu 22 Version
https://github.com/Slait/Keyhuntbsgs/releases/tag/1.0.6.20260306

Thank you, very much!

[arulbero]

.....

I tried your version.
Indeed, it's faster than Alberto’s version - about 2× faster with your bloom tables. I also tried using fuse tables, but I don’t have enough SSD resources.
However, it’s still not worth it. It solves puzzle 80 in about 28 minutes and 14 seconds (including the time needed to fill the tables into memory) at an average speed of ~354 Ekeys/s.

Code:

./keyhunt -m bsgs -f 80.txt -r 80000000000000000000:ffffffffffffffffffff -n 0x1000000000000 -k 16384 -t 192 -q -S -s 1
[+] Version 1.0.4.20260113 Slait Edition, developed by AlbertoBSD
[+] K factor 16384
[+] Threads : 192
[+] Quiet thread output
[+] Stats output every 1 seconds
[+] Mode BSGS sequential
[+] Opening file 80.txt
[+] Added 1 points from file
[+] Range
[+] -- from : 0x80000000000000000000
[+] -- to   : 0xffffffffffffffffffff
[+] N = 0x1000000000000
[+] Bloom filter for 274877906944 elements : 942249.56 MB
[+] Bloom filter for 8589934592 elements : 29445.30 MB
[+] Bloom filter for 268435456 elements : 920.17 MB
[+] Allocating 4096.00 MB for 268435456 bP Points



[+] Thread 0xea0f593a000000000000 | [500853889413563373584384 keys][1414 sec][~354 Ekeys/s (354210671438163630540 keys/s)]
[+] Thread Key found privkey ea1a5c66dcc11b5ad180
[+] Publickey 037e1238f7b1ce757df94faa9a2eb261bf0aeb9f84dbf81212104e78931c2a19dc
All points were found
28m 14s

I also tried random mode (-R) on puzzle 80, but it’s even harder — I couldn’t find anything after letting it run for more than an hour.
RCkangaroo solves the same puzzle 80 in less than 1 minute on an RTX 4080.
So the difference is clear. It’s not worth it, even on my high-end specs:

AMD EPYC 9965 (192 cores / 384 threads)
1 TB DDR5 6400 MT/s
2TB Samsung 990 PRO

So, anyone thinking about investing in expensive hardware components should think twice.

Here is the proof with puzzle 75, only a few seconds for this low bits puzzle. The speed is good but currently it's not worth it on CPU, just my thought.
....

If you look at my program (it uses a modified kangaroo version for cpu):

https://bitcointalk.org/index.php?topic=5576797.0

size of the database = 6GB

On AWS (c8id.metal-48xl instance, 96 core 3.9 GHz, 2 thread for each core -> 96 cores, 192 threads, then this machine is slower than yours):

- sequential search: 0.46 seconds for each key (192 workers, 20 batch_k, 74-75 bit range)
- parallel search: 0.072 seconds for each key (192 workers, 60 batch_k, 74-75 bit range)
- parallel search: 6 seconds for each key (192 workers, 60 batch_k, 80-81 bit range)
- parallel search: about 45 seconds for each key (192 workers, 60 batch_k, 84-85 bit range)