Keyhunt - development requests - bug reports

[Ovixx]

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

how mutch hash i can get with e5-2699 v4 and 256 gb ram?

It's like asking on the forum what the weather is like outside, when you can open the door, you go out and convince yourself.

[thunderbolt1978]

how mutch hash i can get with e5-2699 v4 and 256 gb ram?

who knows??? 🤷

2697v4 128gb ram, i guess double... around 3Ekeys/s

• 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!
• Thread 0x3cdf67df043da02a45f3290d7b3eecb9c  conds: ~1 Ekeys/s (1945754752221815642 keys/s)

3970X 128Gb RAM

+] Making checkums .. ... done

• Sorting 33554432 elements... Done!
• Writing bloom filter to file keyhunt_bsgs_4_34359738368.blm .... Done!
• Writing bloom filter to file keyhunt_bsgs_6_1073741824.blm .... Done!
• Writing bP Table to file keyhunt_bsgs_2_33554432.tbl .. Done!
• Writing bloom filter to file keyhunt_bsgs_7_33554432.blm .... Done!
• Thread 0x38c93b54973c7fbb68df07b81d88b50ee  econds: ~1 Ekeys/s (1529332042058244140 keys/s)

testing right now with

2697v4 512GB RAM
3970X 256GB RAM


is my calculation correct ?

130 bit Key = 2^129 keys = 680,564,733,841,876,926,926,749,214,863,536,422,912 keys ?

680,564,733,841,876,926,926,749,214,863,536,422,912 / 1529332042058244140 keys/s = 445.007.830.298.214.485.823 s = 14.111.105.729.902 years ?

[farshadbbb]

how mutch hash i can get with e5-2699 v4 and 256 gb ram?

who knows??? 🤷

2697v4 128gb ram, i guess double... around 3Ekeys/s

• 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!
• Thread 0x3cdf67df043da02a45f3290d7b3eecb9c  conds: ~1 Ekeys/s (1945754752221815642 keys/s)

3970X 128Gb RAM

+] Making checkums .. ... done

• Sorting 33554432 elements... Done!
• Writing bloom filter to file keyhunt_bsgs_4_34359738368.blm .... Done!
• Writing bloom filter to file keyhunt_bsgs_6_1073741824.blm .... Done!
• Writing bP Table to file keyhunt_bsgs_2_33554432.tbl .. Done!
• Writing bloom filter to file keyhunt_bsgs_7_33554432.blm .... Done!
• Thread 0x38c93b54973c7fbb68df07b81d88b50ee  econds: ~1 Ekeys/s (1529332042058244140 keys/s)

testing right now with

2697v4 512GB RAM
3970X 256GB RAM


is my calculation correct ?

130 bit Key = 2^129 keys = 680,564,733,841,876,926,926,749,214,863,536,422,912 keys ?

680,564,733,841,876,926,926,749,214,863,536,422,912 / 1529332042058244140 keys/s = 445.007.830.298.214.485.823 s = 14.111.105.729.902 years ?

    the t and cpu single core power mathers

[albert0bsd]

Hi everyone,

I am new in this community and have few questions if you don't mind.

Read the F.... Documentation to know what you need to change to do that



To import it on electrum is its possible conver the privatekey to WIF on
https://www.bitaddress.org/bitaddress.org-v3.3.0-SHA256-dec17c07685e1870960903d8f58090475b25af946fe95a734f88408cef4aa194.html

Option of Wallet Details, then import on electrum following this post:

https://medium.com/@lindseymiles/importing-your-private-keys-into-electrum-bitcoin-wallet-14071ab26dfe

[wilspen]

Friend, I wanted to understand a little about this -R mode and the -B random mode, would the -R mode be completely random? or does it generate a random initial value and continue sequentially? I have this doubt because from time to time, it prints several random points according to the number of threads, but I don't know if this point would be just demonstrative or if it would be a starting point.

and another question would be what is the difference between -R and -B random mode.

[albert0bsd]

Friend, I wanted to understand a little about this -R mode and the -B random mode, would the -R mode be completely random? or does it generate a random initial value and continue sequentially?

it is a Initial random value and N keys secuentially from that point, where default N is 32 bits value is set with -n example

Code:

-n 0x1000000

for 24 bits.
Each thread start with a different point

A
and another question would be what is the difference between -R and -B random mode.

both are the same but -B options are only for BSGS mode.

[psychoid]

Hi Alberto, I wanted to share my case:


https://i.ibb.co/JHbWbPx/Screenshot-2024-07-18-100911.png





is it normal that when using less memory the search works faster?

[albert0bsd]

That depends of your physical memory also of the Operating system. By the whay don't use k above 4096 without SET the N value, any value 4096 without the correct N will lead on a sub-optimal behavior just like your example

That is on the documentation:

https://github.com/albertobsd/keyhunt?tab=readme-ov-file#what-values-use-according-to-my-current-ram

Code:

2 G -k 128
4 G -k 256
8 GB -k 512
16 GB -k 1024
32 GB -k 2048
64 GB -n 0x100000000000 -k 4096
128 GB -n 0x400000000000 -k 4096
256 GB -n 0x400000000000 -k 8192
512 GB -n 0x1000000000000 -k 8192
1 TB -n 0x1000000000000 -k 16384
2 TB -n 0x4000000000000 -k 16384
4 TB -n 0x4000000000000 -k 32768
8 TB -n 0x10000000000000 -k 32768

[benjaniah]

That depends of your physical memory also of the Operating system. By the whay don't use k above 4096 without SET the N value, any value 4096 without the correct N will lead on a sub-optimal behavior just like your example

That is on the documentation:

https://github.com/albertobsd/keyhunt?tab=readme-ov-file#what-values-use-according-to-my-current-ram

Code:

2 G -k 128
4 G -k 256
8 GB -k 512
16 GB -k 1024
32 GB -k 2048
64 GB -n 0x100000000000 -k 4096
128 GB -n 0x400000000000 -k 4096
256 GB -n 0x400000000000 -k 8192
512 GB -n 0x1000000000000 -k 8192
1 TB -n 0x1000000000000 -k 16384
2 TB -n 0x4000000000000 -k 16384
4 TB -n 0x4000000000000 -k 32768
8 TB -n 0x10000000000000 -k 32768

Could you recommend a k and n setting for 96 GB?

[albert0bsd]

Could you recommend a k and n setting for 96 GB?

maybe
-n 0x400000000000 -k 3072

[maseratti007]

AlbertoBSD

In BSGS Mode what is the difference between "Random" and "Dance"? Are both good for long ranges?

Thanks for any clarification! 

[powerusa]

AlbertoBSD

In BSGS Mode what is the difference between "Random" and "Dance"? Are both good for long ranges?

Thanks for any clarification! 

Sequential Mode: This mode searches for the private key in a sequential manner, from a starting point and incrementing step by step. It is straightforward but can be slow if the target key is far from the starting point.

Backward Mode: In this mode, the search starts from a specified point and moves backward. This can be useful if you have reason to believe the key might be located before a certain point.

Both Mode: This mode combines both forward and backward searching. The algorithm searches in both directions simultaneously, which can increase the chances of finding the key faster compared to only moving in one direction.

Random Mode: Instead of following a linear path, the search jumps to random positions. This mode can help in scenarios where the key is not expected to be near the starting point and can be located anywhere in the search space.

Dance Mode: This is a more advanced and less predictable search pattern, potentially combining aspects of the other modes in a dynamic way. The exact implementation details can vary, but the goal is to maximize the coverage of the search space and increase the likelihood of finding the key efficiently.

[maseratti007]

AlbertoBSD

In BSGS Mode what is the difference between "Random" and "Dance"? Are both good for long ranges?

Thanks for any clarification! 

Sequential Mode: This mode searches for the private key in a sequential manner, from a starting point and incrementing step by step. It is straightforward but can be slow if the target key is far from the starting point.

Backward Mode: In this mode, the search starts from a specified point and moves backward. This can be useful if you have reason to believe the key might be located before a certain point.

Both Mode: This mode combines both forward and backward searching. The algorithm searches in both directions simultaneously, which can increase the chances of finding the key faster compared to only moving in one direction.

Random Mode: Instead of following a linear path, the search jumps to random positions. This mode can help in scenarios where the key is not expected to be near the starting point and can be located anywhere in the search space.

Dance Mode: This is a more advanced and less predictable search pattern, potentially combining aspects of the other modes in a dynamic way. The exact implementation details can vary, but the goal is to maximize the coverage of the search space and increase the likelihood of finding the key efficiently.

Thank You Very Much!!!