Keyhunt - development requests - bug reports

[albert0bsd]

If so, why still people discussing about it anyway?

Because always it's possible (with enough hash rate)mine a block with your private Transaction on it, ( yourself or a miner )

[citb0in]

Because always it's possible (with enough hash rate)mine a block with your private Transaction on it, ( yourself or a miner )

yeah, you need just some tons of hashpower, better some Exahashes/sec and a lot of patience

[albert0bsd]

I just understand a little of Portuguese. I Only know Spanish and English.

Alberto, eu estava mesmo pensando nisso, sobre eu mesmo minerar o bloco, mas dai daria mais trabalho, pelo hashrate necessário.
Mas dai a minha dúvida.
Supondo que tivesse poder pra minerar, o processo não seria:
1 - Colocar a transação na mempool;
2 - Minerar o bloco?

It is not necessary to broadcast the transaction before mining the block.

Once that miners found a valid hash for their private block, they need to broadcast their full block data, only at that time the transaction will be public. (We are talking of private transactions that are only public once that they are already inside of a mined block).
Obviously that need to be a Custom miner software

You need to learn the full mining process, you need to know about the merkle trees and how block headers need to be build:
https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch12_mining.adoc#constructing-the-block-header

[benjaniah]

I've been using Keyhunt for a long time. It's a great program.
Are there any plans to incorporate an option to also search segwit, native segwit, and taproot addresses simultaneously along with the current legacy compressed/uncompressed addresses?
For example, if you wanted to use Keyhunt, in address mode, to do random searching in the full keyspace against Loyce Club's funded wallet list.
./keyhunt -m address -f tests/Bitcoin_addresses_LATEST.txt -l all -R -t 32 -s 10 (where "-l all" would be compressed, uncompressed, segwit, native segwit, taproot)

I know people say it's pointless but it'd be fun to try.

[Viniciof]

Hello,

I have been testing and playing with keyhunt, very impressive and fast.  Recently, I tested bsgsd sever and it also is pretty fast:

time echo "0365ec2994b8cc0a20d40dd69edfe55ca32a54bcbbaa6b0ddcff36049301a54579 4000000000000000:8000000000000000" | nc -v localhost 8080
Ncat: Version 7.80
Ncat: Connected to 127.0.0.1:8080.
7cce5efdaccf6808Ncat: 101 bytes sent, 16 bytes received in 2.95 seconds.
real    0m2.961s
user    0m0.022s
sys     0m0.004s

I know printing to screen will cause lost of speed but, is there any way I can check exactly how many keys/s are running  in bagsd? With debug or something similar to what keyhunt shows, just for testing. I was able to run bsgsd from a little shell scrip so I can handle some specific ranges without restarting bsgsd each time (it takes half an hour for server to startup), after that, I could get 5E.

Will be any speed improvement in the future for bsgsd or bsgs key generator?

albert0bsd, thanks for all your work!!!

[albert0bsd]

I tested bsgsd sever and it also is pretty fast

Nice, not much people test it because not much knows that the server exists 

I know printing to screen will cause lost of speed but, is there any way I can check exactly how many keys/s are running  in bsgsd?

To keep the best performance in the server i should recommend not to look for this on the server side.

Instead of it i should recommend to this on client side, in the BSGSD.md file i post a small python client, since performance is not required on client python fit perfectly for this situation, you can send small chunks of work to the server something like 50 to 55 bits of subrange and edit the client output to print the speed:

Code:

# Loop for sending and receiving messages
for i in range(num_iterations):
    reply, elapsed_time = send_and_receive_line(host, port, message)
    if reply is not None:
        # speed = subrange / elapsed_time
        print(f'Received reply: {reply}')
        print(f'Elapsed time: {elapsed_time} seconds')
        # print(f'Speed: {speed} keys / seconds')

In that code you need to set the sub-range value, this require to know what are you doing but you can get more or less the speed that you are getting in each time.
I hope this workaround fit your needs because to be honest i don't see any necessary to print the speed on the server side, it was made to attend clients without the need to be in front the same terminal.

Will be any speed improvement in the future for bsgsd or bsgs key generator?

For CPU i doubt it, I already did a lot of improvements compared against the BSGS of JLP i think that i realdy reach the CPU speed limit.
The only possible improvement will be implement another faster storage for the Baby table and bloom filters or the use of GPU (It need to rewrite all the code)

albert0bsd, thanks for all your work!!!

Thanks, you're more than welcome.

Regards!

[Viniciof]

Thanks for the answer and help, I'm just a newbie but could play around a little bit!

[Ovixx]

Hello Alberto. I built a new computer with better performance than the old one, in order to establish a higher value of the K factor. I have 192 GB DDR5 memory and Intel i9-14900K CPU. After I installed Windows 11, I installed the keyhunt application on WSL, but any of the K value I put, it gives me an error when saving the *.blm file. I ask you for advice to solve the problem. I tried from K = 8192, 4096 I went down to K = 256 and in vain. The problem is not from the value of K. I mention that I have enough free space, 1.28TB on a Samsung PRO SSD with 7000 MB read/write. Thank you in advance!

Code:

ovix@DESKTOP-Z790:~/keyhunt$ ./keyhunt -t 2 -m bsgs -f tests/130.txt -r 200000000000000000000000000000000:3ffffffffffffffffffffffffffffffff -q -s 10 -S -k 256 -R
[+] Version 0.2.230519 Satoshi Quest, developed by AlbertoBSD
[+] Threads : 2
[+] Quiet thread output
[+] Stats output every 10 seconds
[+] K factor 256
[+] Random mode
[+] Mode BSGS random
[+] Opening file tests/130.txt
[+] Added 1 points from file
[+] Range
[+] -- from : 0x200000000000000000000000000000000
[+] -- to   : 0x3ffffffffffffffffffffffffffffffff
[+] N = 0x100000000000
[+] Bloom filter for 1073741824 elements : 3680.66 MB
[+] Bloom filter for 33554432 elements : 115.02 MB
[+] Bloom filter for 1048576 elements : 3.59 MB
[+] Allocating 16.00 MB for 1048576 bP Points
[+] processing 1073741824/1073741824 bP points : 100%
[+] Making checkums .. ... done
[+] Sorting 1048576 elements... Done!
[E] Error can't create the file keyhunt_bsgs_4_1073741824.blm
ovix@DESKTOP-Z790:~/keyhunt$

[powerusa]

Hello Alberto,

Can you please add the in GitHub ZEC donation address?

Addicted to the program, also I think you should accept private donations not everybody wants to reveal their wallets to the world.

THX

[albert0bsd]

Hello Alberto. I built a new computer with better performance than the old one, in order to establish a higher value of the K factor. I have 192 GB DDR5 memory and Intel i9-14900K CPU. After I installed Windows 11, I installed the keyhunt application on WSL, but any of the K value I put, it gives me an error when saving the *.blm file. I ask you for advice to solve the problem. I tried from K = 8192, 4096 I went down to K = 256 and in vain. The problem is not from the value of K. I mention that I have enough free space, 1.28TB on a Samsung PRO SSD with 7000 MB read/write. Thank you in advance!

This can be caused y one of three problems

• Not enough privilegies on the current directory
• Not enough space
• WSL configuration

List the current directory with ls -lah to see if "." (current directory) have  your same user and write permissions.
Use df -h to see how many disk space is available.

For the last one please check https://learn.microsoft.com/en-us/windows/wsl/wsl-config.

Can you please add the in GitHub ZEC donation address?

Let me check how to get one, I also plan to add a Monero wallet.

[Ovixx]

I tried with an older version keyhunt, compiled for windows, in two instances simultaneously but it is limited to k=4096. 8192 gives me an error.

Code:

c:\Crypto\keyhunt-win-main\keyhunt-win-main>keyhunt.exe -t 4 -m bsgs -f tests/130.txt -r 200000000000000000000000000000000:2ffffffffffffffffffffffffffffffff -q -s 10 -S -k 4096 -R
[+] Version 0.2.211222 SSE Server Edition ,modify Dusky Kam 3,compiled by @XopMC for t.me/brythbit, developed by AlbertoBSD, developed by AlbertoBSD
[+] Threads : 4
[+] Quiet thread output
[+] Stats output every 10 seconds
[+] K factor 4096
[+] Random mode
[+] Mode BSGS random
[+] Opening file tests/130.txt
[+] Added 1 points from file
[+] Range
[+] -- from : 0x200000000000000000000000000000000
[+] -- to   : 0x2ffffffffffffffffffffffffffffffff
[+] N = 0x100000000000
[+] Bloom filter for 17179869184 elements : 58890.60 MB
[+] Bloom filter for 536870912 elements : 1840.33 MB
[+] Bloom filter for 16777216 elements : 57.51 MB
[+] Allocating 256.00 MB for 16777216 bP Points
[+] Reading bloom filter from file keyhunt_bsgs_4_17179869184.blm .... Done!
[+] Reading bloom filter from file keyhunt_bsgs_6_536870912.blm .... Done!
[+] Reading bP Table from file keyhunt_bsgs_2_16777216.tbl .... Done!
[+] Reading bloom filter from file keyhunt_bsgs_7_16777216.blm .... Done!
[+] Total 293337334983847575552 keys in 1430 seconds: ~205 PetaKeys/s (205131003485208094 keys/s)

Code:

[+] Bloom filter for 34359738368 elements       0 [main] keyhunt 1032 cygwin_exception::open_stackdumpfile: Dumping stack trace to keyhunt.exe.stackdump

c:\Crypto\keyhunt-win-main\keyhunt-win-main>keyhunt.exe -t 4 -m bsgs -f tests/130.txt -r 300000000000000000000000000000000:3ffffffffffffffffffffffffffffffff -q -s 10 -S -k 4096 -R
[+] Version 0.2.211222 SSE Server Edition ,modify Dusky Kam 3,compiled by @XopMC for t.me/brythbit, developed by AlbertoBSD, developed by AlbertoBSD
[+] Threads : 4
[+] Quiet thread output
[+] Stats output every 10 seconds
[+] K factor 4096
[+] Random mode
[+] Mode BSGS random
[+] Opening file tests/130.txt
[+] Added 1 points from file
[+] Range
[+] -- from : 0x300000000000000000000000000000000
[+] -- to   : 0x3ffffffffffffffffffffffffffffffff
[+] N = 0x100000000000
[+] Bloom filter for 17179869184 elements : 58890.60 MB
[+] Bloom filter for 536870912 elements : 1840.33 MB
[+] Bloom filter for 16777216 elements : 57.51 MB
[+] Allocating 256.00 MB for 16777216 bP Points
[+] Reading bloom filter from file keyhunt_bsgs_4_17179869184.blm .... Done!
[+] Reading bloom filter from file keyhunt_bsgs_6_536870912.blm .... Done!
[+] Reading bP Table from file keyhunt_bsgs_2_16777216.tbl .... Done!
[+] Reading bloom filter from file keyhunt_bsgs_7_16777216.blm .... Done!
[+] Total 240737507951601778688 keys in 1190 seconds: ~202 PetaKeys/s (202300426850085528 keys/s)

The problem is that it has raised the CPU to 104 degrees Celsius.

[powerusa]

Alberto.

I recommend https://electriccoin.co/zashi/ or any other supporting shielded and unshielded addresses.


Also how close are you to developing GPU support?