Pages:
Author

Topic: Keyhunt - development requests - bug reports - page 12. (Read 15639 times)

member
Activity: 124
Merit: 37
September 03, 2023, 02:54:13 PM
Hello Alberto thanks for the reply.
>>what are you looking in the 256 bit range?

Puzzle 256. I will try -r 256. I use the PC as a heater in my office as a lottery function when it is cold.  Grin

using -r 256 indeed the range is much more random, 0x10 seen. so my observation would only seem to be with the default range.

Thanks for the reply
hero member
Activity: 862
Merit: 662
September 02, 2023, 09:18:44 PM
Just been watching the threads go by in random mode.
I notice that the first byte never seems to go below 0x7f. usually OxB -0xF range. is it just me? or perhaps the way the display is set.

Hi thank to point this, it is not exactly an issue, Keyhunt just needs a little guidance from you if you want to target a specific range. Let me explain how you can do this effectively.

Keyhunt by default, it searches exclusively on bit 256, to avoid this limitation, you can specify the range you're interested in using the '-r' option.

Code:
-r 1:fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141

In the code above, '-r' allows you to set a range, and the numbers following it define the range. By specifying the range you want to target, you can make Keyhunt work exactly as you need it to.

Just a personal question, what are you looking in the 256 bit range? Usually keyhunters only target the lastest avaiable puzzle in this case puzzle 130 with -b 130 you can specify the exact range of that puzzle.

Publickey:

Code:
03633CBE3EC02B9401C5EFFA144C5B4D22F87940259634858FC7E59B1C09937852

Code:
./keyhunt -m bsgs -f file.txt  -R -k 128 -S -t 8 -M -b 130

If you have any more questions or need further clarification, feel free to ask.

Happy hunting!
member
Activity: 124
Merit: 37
September 02, 2023, 07:33:28 PM
Just been watching the threads go by in random mode.
I notice that the first byte never seems to go below 0x7f. usually OxB -0xF range. is it just me? or perhaps the way the display is set.

my command :
./keyhunt -m bsgs -f file.txt  -R -k 128 -S -t 30

some samples,
I realize it is random but I have been watching for 1/2 hour or so and this is typical.
  • Thread 0xbcfa84cfca81c98d82d467e9d28fc3a3dd4ee29afbd55f5b43764098788d1b2c
  • Thread 0xe16f1d5a2b56d0f1f1358e49b4a9bc2008a134553465875519b54eeb1b1a5e94
  • Thread 0xb5ddd335a7e5b81a8c535d877b663a241140d5d734f4175cfd3944f1216f1350
  • Thread 0xbefe4dee80707a3cf10ab12aa3b38bfab5a25aeb077d63d598347beab42e1e64
  • Thread 0xd8a697fe28b043b2dbd7a4411a3dabb276eb8e371599e16892b831b0778746f8
  • Thread 0xe0453e32811e046970e77e7f330ac5b13053e501aeeec5bc4a1d10c9ceb65a6e
  • Thread 0xe84bc918f376f95c0336b9490994ae831b1bb02bda2e15890c5eafe8b65acf08
  • Thread 0xad06eccd87e49e534b399fc25b5b20235f354c68b16e9496d70b4b1832668140
  • Thread 0xec5d5430d9cf8040437bab579cf267c703d1fc3c004fc5a289714fa71cd12651
  • Thread 0xb5f8006e7ec5f808b2c3baa302129b03372675febff9c65057d47b75f1cd038b
  • Thread 0xf882f18e9c06309224a094087fed549239a7cd2571d30a7fda8c605a4e08170b
  • Thread 0xf89202125b4c3926122c572090b3366599b664fbc546aae5ee12bc81b357e07b
  • Thread 0xcd4b35a83560269e9dd7eca1a0cf224360ce1825d1b07a141c881c6dab2877e8
  • Thread 0xee9c62800cf987c434661b6462fba1d099e924235184fe4663f1238ca14912cf
  • Thread 0xce6995d50d122073e37682b140bcc44c74a03656b5c5207bfc3d2f50e108d05e
  • Thread 0xb8a37384ba86093849ab40a11a3585f1659ebc1a1824e3576a1e3fa877ac0eba
  • Thread 0xfb37dbea876cd6b07ace3ae16fed7658161e164c9de83e1a8152195c8dd45b2d
  • Thread 0xdbe9afef48d79d4bb19dbb58a1ad27fb7a0693fac221ae6202ecc4ca12c39dc7
  • Thread 0xb03ce99af487e4324c08351e5001d0cc28dd7339ee285478a5058a7b0e1dcf5a
  • Thread 0xed8a59f420aaf6b2b84b3a6fd20271a81b99268a530946e9a8b44b9e3c4d572a
  • Thread 0xd17b09bc645a1e0dae79b7f477d2269301149c4491d9232b8d948b2733d874a8
  • Thread 0xbe27ebfcf204b1b37ddc8b49d9225d17ed8bd69429dc27ba1d05c76cc9f515ca
  • Thread 0xdeb65bb23a27dd9bd0292309aaf172f82592db58ce9c87bb2ad1c415816422f3
  • Thread 0xb4dd6fe12f45e934a8b82becc2f7094f9c5b10d7130444f63fd2d044c51927d0
  • Thread 0xb3031e6a12475128a9eb5aad6d3b78eaa993e687f6fc75679b43634ab65703c6
  • Thread 0xf63ec131cf04ad514fb7a1c55b81ea4e6b80d78dbd1fec0fdfd904324d00ecd5
  • Thread 0xff2c6a3bfe96020af3a883a91a9677363185c84b731e2779c19b7e1496eee927

Thanks for an excellent program
newbie
Activity: 29
Merit: 0
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.
It is  happen to be using a xmrig on the same machine as Keyhunt.

Is it possible to boost command from here increase the number of keys per second on AMD EPYC

https://raw.githubusercontent.com/xmrig/xmrig/dev/scripts/randomx_boost.sh

I have strange results. Grin
You may start xmrig with any randomx coin using --randomx-no-rdmsr command or rdmsr: false in config file. It would keep the msr mod enabled on exit. Quit xmrig when you see msr mod was applied and start keyhunt or whatever cpu app you want. Check the performance difference with earlier results.
newbie
Activity: 14
Merit: 0
The whole thing is confusing and I think I need a simple language to understand this. I think this development gonna be interesting if well explain, am new here thanks
hero member
Activity: 862
Merit: 662
Is it possible to change the search step, for example, not 00001 - 00002 - 00003, but 01000 - 02000 - 03000 Huh

Not yet.

About the xmrig I never heard about it, I think that it can't be used for this purposes
newbie
Activity: 7
Merit: 5
There is an example of the address format in the documentation, please check it.

About the speed, the hashing process for eth it is more slow than the process for Bitcoin. Also there are some calculations that can't be avoided for eth, and those calcs can be avoided for Bitcoin address then  it will be more slow for eth than bitcoin



Thank you
Is it possible to change the search step, for example, not 00001 - 00002 - 00003, but 01000 - 02000 - 03000 Huh
member
Activity: 507
Merit: 38
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.
It is  happen to be using a xmrig on the same machine as Keyhunt.

Is it possible to boost command from here increase the number of keys per second on AMD EPYC

https://raw.githubusercontent.com/xmrig/xmrig/dev/scripts/randomx_boost.sh

I have strange results. Grin
newbie
Activity: 37
Merit: 0
Alberto: https://github.com/albertobsd/keyhunt/issues/241

Also, any hints how I can make this faster?

Code:
./keyhunt -m rmd160 -f tests/unsolvedpuzzles.rmd -r 20000000000000000:ffffffffffffffffffffffffffffffffffffffff -l compress -s 5 -S -q -c btc -k 2048 -t 128 -S
[+] Version 0.2.230519 Satoshi Quest, developed by AlbertoBSD
[+] Mode rmd160
[+] Search compress only
[+] Stats output every 5 seconds
[+] Quiet thread output
[+] K factor 2048
[+] Threads : 128
[+] N = 0x100000000
[+] Range
[+] -- from : 0x20000000000000000
[+] -- to   : 0xffffffffffffffffffffffffffffffffffffffff
[+] Reading file data_b7aecab7.dat
[+] Bloom filter for 10000 elements.
[+] Allocating memory for 84 elements: 0.00 MB
[+] Total 9923289088 keys in 30 seconds: ~330 Mkeys/s (330776302 keys/s)
hero member
Activity: 862
Merit: 662
There is an example of the address format in the documentation, please check it.

About the speed, the hashing process for eth it is more slow than the process for Bitcoin. Also there are some calculations that can't be avoided for eth, and those calcs can be avoided for Bitcoin address then  it will be more slow for eth than bitcoin
newbie
Activity: 7
Merit: 5
Tell me how to use eth mode, when reading addresses from a file, it does not find the necessary addresses when searching, and why is the speed so low?
are there any other programs that work with address databases for ethereum? Thank you.
newbie
Activity: 30
Merit: 0

Where can I find these public key puzzles?

Sorry, very new in this.

#130:::::#160

Code:
03633cbe3ec02b9401c5effa144c5b4d22f87940259634858fc7e59b1c09937852
02145d2611c823a396ef6712ce0f712f09b9b4f3135e3e0aa3230fb9b6d08d1e16
031f6a332d3c5c4f2de2378c012f429cd109ba07d69690c6c701b6bb87860d6640
03afdda497369e219a2c1c369954a930e4d3740968e5e4352475bcffce3140dae5
03137807790ea7dc6e97901c2bc87411f45ed74a5629315c4e4b03a0a102250c49
035cd1854cae45391ca4ec428cc7e6c7d9984424b954209a8eea197b9e364c05f6
02e0a8b039282faf6fe0fd769cfbc4b6b4cf8758ba68220eac420e32b91ddfa673
hero member
Activity: 862
Merit: 662
Any output transaction? Aren't the new transaction scripts protocols avoiding exposing public keys at all? I had the idea that only in very old transactions outputs could you find public keys.

Yes any output Transaction expose the Publickey (a set of data TX script, R,S and "P" where P is the publickey ), I've not checked new Transaactions but all need to expose publickey, if the publickeys is not there maybe there is enough information to calculate the possible Keys (a set of data TX script, R,S and V, where V is some byte that can calculate the P value, just like the Ethereum network), but that is beyond of this topic.
newbie
Activity: 37
Merit: 0

Where can I find these public key puzzles?

Sorry, very new in this.

Not all puzzles have it available only those that have some Output transaction.
Any output transaction? Aren't the new transaction scripts protocols avoiding exposing public keys at all? I had the idea that only in very old transactions outputs could you find public keys.
hero member
Activity: 862
Merit: 662

Where can I find these public key puzzles?

Sorry, very new in this.

Not all puzzles have it available only those that have some Output transaction.
newbie
Activity: 37
Merit: 0
You cant use BSGS for 66. Public key is not visible. You can only use BSGS for known public keys, and the source you provide, you arent using BSGS, you are using normal -m address which refers to normal bruteforce. You need to use the -m -bsgs commandline. for BSGS fast speed

I see, thanks for explaining.

What would you recommend using in #66? -m address with 66.txt or -m rmd160 with 66.rmd? Any pros and cons of each vs the other?

Can I leverage my RAM in -m address or -m rmd160 to make it faster, or only BSGS has that benefit?
Why would you wanna waste time and energy on address only puzzles when you can spend the same time and use the same resources to search for puzzles with known public keys,  either learn how to utilize bsgs for public keys or use kangaroo.

Where can I find these public key puzzles?

Sorry, very new in this.
copper member
Activity: 1330
Merit: 900
🖤😏
You cant use BSGS for 66. Public key is not visible. You can only use BSGS for known public keys, and the source you provide, you arent using BSGS, you are using normal -m address which refers to normal bruteforce. You need to use the -m -bsgs commandline. for BSGS fast speed

I see, thanks for explaining.

What would you recommend using in #66? -m address with 66.txt or -m rmd160 with 66.rmd? Any pros and cons of each vs the other?

Can I leverage my RAM in -m address or -m rmd160 to make it faster, or only BSGS has that benefit?
Why would you wanna waste time and energy on address only puzzles when you can spend the same time and use the same resources to search for puzzles with known public keys,  either learn how to utilize bsgs for public keys or use kangaroo.
newbie
Activity: 37
Merit: 0
You cant use BSGS for 66. Public key is not visible. You can only use BSGS for known public keys, and the source you provide, you arent using BSGS, you are using normal -m address which refers to normal bruteforce. You need to use the -m -bsgs commandline. for BSGS fast speed

I see, thanks for explaining.

What would you recommend using in #66? -m address with 66.txt or -m rmd160 with 66.rmd? Any pros and cons of each vs the other?

Can I leverage my RAM in -m address or -m rmd160 to make it faster, or only BSGS has that benefit?
member
Activity: 200
Merit: 14
You cant use BSGS for 66. Public key is not visible. You can only use BSGS for known public keys, and the source you provide, you arent using BSGS, you are using normal -m address which refers to normal bruteforce. You need to use the -m -bsgs commandline. for BSGS fast speed
newbie
Activity: 37
Merit: 0
another question haunts me, about the two modes:
- - normal search over the entire 66 range (./keyhunt -m rmd160 -f tests/66.rdb 66 -l compress -R -q)
- - or still bsgs by public key (./keyhunt -m bsgs -f tests/125.txt -b 125 -q -s 10 -R)
on the one hand, the 66 range is less than (total) 73786976294838206463 and the 125th is already 42535295865117307932921825928971026431
it turns out 66 I can take the number of possible keys and divide by the speed, then I will understand how much I need to search for the key.
but on the other hand, the public key search algorithm is not a simple search, how to estimate how many possible steps in bsgs?

Where did you get that 66.rdb?
Pages:
Jump to: