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.