Keyhunt - development requests - bug reports

[digaran]

Guys how do I store a few GB of public keys/data in compressed format and when I have done it, do I need a tool to be able to read such data?

Because notepad becomes unresponsive when we load it with even less than a GB.
I'd appreciate if anyone can help.
Regards ~ dig.

[lostrelic]

Guys how do I store a few GB of public keys/data in compressed format and when I have done it, do I need a tool to be able to read such data?

Because notepad becomes unresponsive when we load it with even less than a GB.
I'd appreciate if anyone can help.
Regards ~ dig.

Emeditor

[albert0bsd]

Can use it for get ecdsa K value to recover Private key ?

Why you quoted all my post? Anyway your question is not specific, what are you trying to do? I know what are you talking about but do you know what are you trying to achieve? It is some special case?

[hhhhugi]

Dear albert0bsd,

Which GPU do you recommend on Keyhunt-Cuda?

Do you have information about benchmarking result on latest 3090, 4090 or Tesla 32gb cards?

I want to open this thread to talk about the tool that i develop Keyhunt available on github.

https://github.com/albertobsd/keyhunt

Telegram group

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:

Code:

./keyhunt -m bsgs -f 120.txt -b 120 -R

output

Code:

[+] Version 0.1.20210321 K*BSGS
[+] Setting mode BSGS
[+] Min range: 800000000000000000000000000000
[+] Max range: ffffffffffffffffffffffffffffff
[+] Setting random mode.
[+] Opening file 120.txt
[+] Added 1 points from file
[+] Bit Range 120
[+] Setting N up to 17592186044416.
[+] Init 1st bloom filter for 4194304 elements : 14.00 MB
[+] Init 2nd bloom filter for 209716 elements : 0.00 MB
[+] Allocating 128.0 MB for 4194304 aMP Points
[+] Precalculating 4194304 aMP points
[+] Allocating 3.00 MB for 209716 bP Points
[+] precalculating 4194304 bP points
[+] Sorting 209716 elements
[+] Thread 0: 000000000000000000000000000000000092dd2b47cff81ad94120bf853ef87f
[+] Thread 0: 0000000000000000000000000000000000f7fe7fccb98e136a97c2fa9d41de7b
[+] Thread 0: 00000000000000000000000000000000008d4882d7f596851a73ae35543c4dcd
Total 35184372088832 keys in 30 seconds: 1172812402961 keys/s
[+] Thread 0: 00000000000000000000000000000000009e80f97d3e3ff0fddbdcf02894e41d
^C

Speed: 1 Terakeys/s

Well in that example (same in github) we can reach 1Terakeys/s with one thread.

Wan to more speed? use the "-k value" param to boots the speed

Code:

./keyhunt -m bsgs -f 120.txt -b 120 -R -k 20

Output:

Code:

[+] Version 0.1.20210321 K*BSGS
[+] Setting mode BSGS
[+] Min range: 800000000000000000000000000000
[+] Max range: ffffffffffffffffffffffffffffff
[+] Setting random mode.
[+] Setting k factor to 20
[+] Opening file 120.txt
[+] Added 1 points from file
[+] Bit Range 120
[+] Setting N up to 17592253153280.
[+] Init 1st bloom filter for 83886080 elements : 287.00 MB
[+] Init 2nd bloom filter for 4194304 elements : 14.00 MB
[+] Allocating 6.0 MB for 209716 aMP Points
[+] Precalculating 209716 aMP points
[+] Allocating 64.00 MB for 4194304 bP Points
[+] precalculating 83886080 bP points

[+] Sorting 4194304 elements
(Thread output omited....)
Total 703690126131200 keys in 30 seconds: 23456337537706 keys/s
(More thread output omited....)
Total 2814760504524800 keys in 120 seconds: 23456337537706 keys/s

Speed: ~23 Terekeys/s

Tips

• you can quiet the thread output with -q
• you can load the precalcutalted bPtable -p yourfile.bin

Do you still want to more speed? Well Use more RAM, the -k 128 will use some 2.5 GB of RAM

This file will take some minutes for the value -k 128, but the speed worth it!

Code:

./keyhunt -m bsgs -f 120.txt -b 120 -R -k 128 -p ./bPfile.bin

Output:

Code:

[+] Version 0.1.20210321 K*BSGS
[+] Setting mode BSGS
[+] Min range: 800000000000000000000000000000
[+] Max range: ffffffffffffffffffffffffffffff
[+] Setting random mode.
[+] Setting k factor to 128
[+] Opening file 120.txt
[+] Added 1 points from file
[+] Bit Range 120
[+] Setting N up to 17592186044416.
[+] Init 1st bloom filter for 536870912 elements : 1840.00 MB
[+] Init 2nd bloom filter for 26843546 elements : 92.00 MB
[+] Allocating 1.0 MB for 32768 aMP Points
[+] Precalculating 32768 aMP points
[+] Allocating 409.00 MB for 26843546 bP Points
[+] Reading 536870912 bP points from file ./bPfile.bin
[+] Sorting 26843546 elements
(Thread output omited....)
Total 4345269952970752 keys in 30 seconds: 144842331765691 keys/s
(More thread output omited....)
Total 17539409486282752 keys in 120 seconds: 146161745719022 keys/s

Speed: ~146 Terakeys/s one single thread

OK at this point maybe you want to use ALL your RAM memory to solve the puzzle 120, just a bigger -k value

I already tested it with some 24 GB used with -k 1024 and I get 1.16 Petakeys/s per thread.

Using the same configuration with 4 threads I get 4.5 Petakeys/s total

Image:
https://albertobsd.dev/uploads/1616428067_bd1fc052-9441-4cbb-9bd1-d2e393489e18.jpg


FAQ

Q: Why the Progress is not displayed?
R: The speed depent of the number of target publickeys if you load 1000 publickeys, it will take some more time, the speed is only displayed when at least one thread finish one of his cycles

Q: Can we faster this code with Gpu?
R: Well yes, but the BSGS algo use RAM, only high end video cards have a lot of RAM, for GPU is better to use Kangaroo

Q: How long will take the scan the 120 bit range?
R: Human brain usually can't handle big numbers, the 120 bit space have 664613997892457936451903530140172287 (six hundred sixty four decillion...) and we speed is about 1000000000000 (one trillion or one terakey/s) the spected time acording with your speed is:

Code:

Puzzle 120 @ 1 Terakeys/s :     21074771622667996 years
Puzzle 120 @ 1 Petakeys/s :     21074771622667 years

Q: Why should i keep using brute force tools?
R: You should not, but people hope in luck.

Q: Is avaible for Windows?
R: Natively no, but you can install the ubuntu shell for windows and compile it from there

Q: It have dependencies?
R: Just libgmp for BigIntegers install it with

Code:

apt-get install  libgmp3-dev

Q: Why your program use alot of RAM?
R: Actuallly i keep in RAM two things (Bloomfilter and a Full bPTable ) im working in one way to remove or reduce the bPTable.

Nexts releases

• BSGS with K factor Release in 6/March
• Network/Pool versión
• Pollard rho

Best regards!

[albert0bsd]

Dear albert0bsd,

Which GPU do you recommend on Keyhunt-Cuda?

Do you have information about benchmarking result on latest 3090, 4090 or Tesla 32gb cards?

I don't develop keyhunt-cuda, also I don't recommend it, it have some bugs that may missing some keys.

[citb0in]

I don't develop keyhunt-cuda, also I don't recommend it, it have some bugs that may missing some keys.

interesting. Can you provide some more detailled information and explain how to reproduce this issue ?

[WanderingPhilospher]

I don't develop keyhunt-cuda, also I don't recommend it, it have some bugs that may missing some keys.

interesting. Can you provide some more detailled information and explain how to reproduce this issue ?

I second this!

Do tell albert0bsd, thank you!

[7isce]

Maybe albert0bsd refer to bug of using -m address (single, NOT -m addresses ) which will miss the key.

[albert0bsd]

Maybe albert0bsd refer to bug of using -m address (single, NOT -m addresses ) which will miss the key.

Not is not that, the bloom filter that he is using have some bugs i report those bugs to the developer of the bloomfilter

https://github.com/jvirkki/libbloom/issues/20

But the developer update it some year before that, i solve by my own implementation.

I notify to KV but he didn't solve as far i can remember

So for small list of address it work fime, but for bigger lists it can fail.

I updated my bloom filter implementation to use xxhash (64 bits) instead of murmurhash (32bits), because with murmurhash if the number of addresses in the list, is near to 32 bits then the bloom may be some saturated because almost any data tha that you pass to the bloom filter will do a collision.

Look the original code in https://github.com/jvirkki/libbloom/blob/master/bloom.c#L57

With a 64 bit hash the problem will be solved, but the original bloom may never change it because compatibility reasons.

the KV version may have some other bugs but since it was some kind of copy of my keyhunt, i prefer to improve my own version than fix another versions.

[citb0in]

as keyhunt-cuda find successful the key for puzzle #65, shouldn't we expect that it works fine for #66, too ?

[albert0bsd]

as keyhunt-cuda find successful the key for puzzle #65, shouldn't we expect that it works fine for #66, too ?

Yes, for small list of address or a single address the bug that I'm describing don't exist, so it will work fine, but i don't know if there are other errors there.

[WanderingPhilospher]

as keyhunt-cuda find successful the key for puzzle #65, shouldn't we expect that it works fine for #66, too ?

Yes, for small list of address or a single address the bug that I'm describing don't exist, so it will work fine, but i don't know if there are other errors there.

Are you saying if your address list contains close to 2^32 addresses, a bug may exist, as you described above?
That’s a large number of addresses!

I’ve ran it with 2^28 addresses and found the key I had put in there as a POW address.

[albert0bsd]

Are you saying if your address list contains close to 2^32 addresses, a bug may exist, as you described above?

Yes the bug exists, but the behaivor of it is unexpected

if you see this PoC:
https://github.com/jvirkki/libbloom/issues/20

Code:

Items 4194304 bloom filter bytes 7537997
Items 8388608 bloom filter bytes 15075994
Items 16777216 bloom filter bytes 30151987
Items 33554432 bloom filter bytes 60303973
Items 67108864 bloom filter bytes 120607946
Items 134217728 bloom filter bytes 241215893
Items 268435456 bloom filter bytes 482431785
Items 536870912 bloom filter bytes 427992657
Items 1073741824 bloom filter bytes 319114402
Items 2147483648 bloom filter bytes 101357891

Why more items in the bloom lead to a lower number of bytes? Look carefully:

Items 268435456 bloom filter bytes 482431785
Items 536870912 bloom filter bytes 427992657
Items 1073741824 bloom filter bytes 319114402
Items 2147483648 bloom filter bytes 101357891

That’s a large number of addresses!

Yes it is, I've seeing people making such amount of list with keysubtract or similar custom tools

I’ve ran it with 2^28 addresses and found the key I had put in there as a POW address.

The bug is only present above a 2^30 list and the hebaivor is unexpected it may hit or not but it need to be tested.

[kknd]

1 Ekeys/s (1021708069969158067 keys/s)

1.021.708.069.969.158.067 keys/s

128gb + 16 AMD Ryzen 7 5800X

Code:

ubuntu@:~/kknd/keyhunt$ ./keyhunt -m bsgs -f 125.pub -b 125 -R -q -S -n 0x400000000000 -k 4096 -t 15
[+] Version 0.2.230428 Satoshi Quest, developed by AlbertoBSD
[+] Random mode
[+] Quiet thread output
[+] K factor 4096
[+] Threads : 15
[+] Mode BSGS random
[+] Opening file 125.pub
[+] Added 1 points from file
[+] Bit Range 125
[+] -- from : 0x10000000000000000000000000000000 [+] -- to   : 0x20000000000000000000000000000000
[+] N = 0x400000000000
[+] Bloom filter for 34359738368 elements : 117781.20 MB
[+] Bloom filter for 1073741824 elements : 3680.66 MB
[+] Bloom filter for 33554432 elements : 115.02 MB
[+] Allocating 512.00 MB for 33554432 bP Points
[+] Reading bloom filter from file keyhunt_bsgs_4_34359738368.blm .... Done!
[+] Reading bloom filter from file keyhunt_bsgs_6_1073741824.blm .... Done!
[+] Reading bP Table from file keyhunt_bsgs_2_33554432.tbl .... Done!
[+] Reading bloom filter from file keyhunt_bsgs_7_33554432.blm .... Done!
[+] Total 82543794972808280276992 keys in 80790 seconds: ~1 Ekeys/s (1021708069969158067 keys/s)

Code:

Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         48 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  16
  On-line CPU(s) list:   0-15
Vendor ID:               AuthenticAMD
  Model name:            AMD Ryzen 7 5800X 8-Core Processor
    CPU family:          25
    Model:               33
    Thread(s) per core:  2
    Core(s) per socket:  8
    Socket(s):           1
    Stepping:            2
    Frequency boost:     enabled
    CPU max MHz:         3800.0000
    CPU min MHz:         2200.0000
    BogoMIPS:            7586.05

[albert0bsd]

1 Ekeys/s (1021708069969158067 keys/s)

1.021.708.069.969.158.067 keys/s

128gb + 16 AMD Ryzen 7 5800X

  Nice config, I really wish you good luck, you will need it


BTW Guys i already update some features in the main branch of my keyhunt repository, here some of the highlighs:

• Added mode vanity at rmd speed because always is cool to have an own custom address
• Merge of Address and rmd160, now they both works at the same speed and also accept file with legacy address or rmd hashed
• Bloom filter and table Saved in file for address, rmd160, xpoint, minikeys, to enable this run always with option -S
• Endomorphism option -e to enable better speed for address, rmd160, xpoint and vanity this allow to search 6 keys at the same time, it not work for puzzles because 5 of each 6 keys will be outside the range.
• Improved Makefile options to optimize it to your current architecture, some users report some increment (%20 to %40) of speed for address, rmd160 and xpoint

Things pending TO-DO in keyhunt  (in order)

• Finish the Double BSGS speed. (I'm having some troubles here but i'm at halfway)
• Legacy version (to run everywhere Linux, Mac, termux)
• Windows Version
• GPU Version
• Pool client Version

best regards

[GR Sasa]

• Added mode vanity at rmd speed because always is cool to have an own custom address
• Merge of Address and rmd160, now they both works at the same speed and also accept file with legacy address or rmd hashed
• Bloom filter and table Saved in file for address, rmd160, xpoint, minikeys, to enable this run always with option -S
• Endomorphism option -e to enable better speed for address, rmd160, xpoint and vanity this allow to search 6 keys at the same time, it not work for puzzles because 5 of each 6 keys will be outside the range.
• Improved Makefile options to optimize it to your current architecture, some users report some increment (%20 to %40) of speed for address, rmd160 and xpoint

Things pending TO-DO in keyhunt  (in order)

• Finish the Double BSGS speed. (I'm having some troubles here but i'm at halfway)
• Legacy version (to run everywhere Linux, Mac, termux)
• Windows Version
• GPU Version
• Pool client Version

best regards

Thank you for your efforts and work. Indeed a GPU and a pool update would be a powerful combine update...

[PawGo]

• Windows Version
• GPU Version

Alberto, what is your plan, any timeline? Do you need help with that? Let me know, maybe we could work together on your software.

[albert0bsd]

Alberto, what is your plan, any timeline? Do you need help with that? Let me know, maybe we could work together on your software.

Hi PawGo, nice to read you.

Actually i haven't a timeline for it, but the plan is that list in that order, at least i hope that. Let me finish with this increment BSGS speed thing and the Legacy version and then i will let you know to work for it

Thanks

[BS0D]

Will there be any speed improvement using AVX2 and hugepages for CPUs? As well as L3 cache usage of ryzen cpus which in some cases may replace ram reads increasing the speed by times.

[citb0in]

Not is not that, the bloom filter that he is using have some bugs i report those bugs to the developer of the bloomfilter
https://github.com/jvirkki/libbloom/issues/20
But the developer update it some year before that, i solve by my own implementation.

I notify to KV but he didn't solve as far i can remember

What or who do you mean by KV ?

So for small list of address it work fime, but for bigger lists it can fail.

Yes, for small list of address or a single address the bug that I'm describing don't exist, so it will work fine, but i don't know if there are other errors there.

Are you saying if your address list contains close to 2^32 addresses, a bug may exist, as you described above? That’s a large number of addresses! I’ve ran it with 2^28 addresses and found the key I had put in there as a POW address.

Yes the bug exists, but the behaivor of it is unexpected

if you see this PoC:
https://github.com/jvirkki/libbloom/issues/20

Code:

Items 4194304 bloom filter bytes 7537997
Items 8388608 bloom filter bytes 15075994
Items 16777216 bloom filter bytes 30151987
Items 33554432 bloom filter bytes 60303973
Items 67108864 bloom filter bytes 120607946
Items 134217728 bloom filter bytes 241215893
Items 268435456 bloom filter bytes 482431785
Items 536870912 bloom filter bytes 427992657
Items 1073741824 bloom filter bytes 319114402
Items 2147483648 bloom filter bytes 101357891

Why more items in the bloom lead to a lower number of bytes? Look carefully:

Items 268435456 bloom filter bytes 482431785
Items 536870912 bloom filter bytes 427992657
Items 1073741824 bloom filter bytes 319114402
Items 2147483648 bloom filter bytes 101357891

If understood correctly the mismatch occurs after 536870912 items, so up to 536,870,912 (2^29) there are no issues and errors in KeyHunt-Cuda implementation by Qalander or Manyu, can anyone confirm this?

I updated my bloom filter implementation to use xxhash (64 bits) instead of murmurhash (32bits), because with murmurhash if the number of addresses in the list, is near to 32 bits then the bloom may be some saturated because almost any data tha that you pass to the bloom filter will do a collision. Look the original code in https://github.com/jvirkki/libbloom/blob/master/bloom.c#L57 With a 64 bit hash the problem will be solved, but the original bloom may never change it because compatibility reasons. the KV version may have some other bugs but since it was some kind of copy of my keyhunt, i prefer to improve my own version than fix another versions.

@albert0bsd
if I read between the lines correctly, there seems to be something bothering you about the versions of KeyHunt-Cuda available on github (I'm thinking of the versions of Qalander and/or Manyu). I'm guessing that you may be upset because they may have stolen code from you or otherwise misused it without giving you credit. But that's just my guess. At least I read out that you have no interest in a cooperation with them. Nevertheless, thank you very much for your work so far and for sharing your programs with the community. Hats off and keep it up!

Out of pure curiosity and personal interest in a working KeyHunt-Cuda version, I'd like to ask you: for what reasons haven't you designed a CUDA-enabled version yet? Working with CPU is completely behind for the purposes after all, GPUs simply have the highest power and performance. Or did you design a KeyHunt-Cuda version in the meantime and I missed it and didn't notice? Am curious and look forward to your answer.

I would be very interested in a multi-GPU CUDA capable KeyHunt versio that comes with a fully functional bloom filter and can handle not only p2pkh legacy (compressed and uncompressed) but also p2sh and bech32 addresses. That would be gigantic. But I know, that's not a wishful thinking and surely needs a lot of work. Does anyone know if something like this already exists ? I am looking forward to your feedback.