Keyhunt - development requests - bug reports

[albert0bsd]

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.

[1715333208]

1715333208

[1715333208]

1715333208

[1715333208]

1715333208

[1715333208]

1715333208

[Ovixx]

Where can I find these public key puzzles?

Sorry, very new in this.

#130:::::#160

Code:

03633cbe3ec02b9401c5effa144c5b4d22f87940259634858fc7e59b1c09937852
02145d2611c823a396ef6712ce0f712f09b9b4f3135e3e0aa3230fb9b6d08d1e16
031f6a332d3c5c4f2de2378c012f429cd109ba07d69690c6c701b6bb87860d6640
03afdda497369e219a2c1c369954a930e4d3740968e5e4352475bcffce3140dae5
03137807790ea7dc6e97901c2bc87411f45ed74a5629315c4e4b03a0a102250c49
035cd1854cae45391ca4ec428cc7e6c7d9984424b954209a8eea197b9e364c05f6
02e0a8b039282faf6fe0fd769cfbc4b6b4cf8758ba68220eac420e32b91ddfa673

[kewa07]

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.

[albert0bsd]

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

[NonFungibleUser]

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)

[nomachine]

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.

[kewa07]

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

[albert0bsd]

Is it possible to change the search step, for example, not 00001 - 00002 - 00003, but 01000 - 02000 - 03000

Not yet.

About the xmrig I never heard about it, I think that it can't be used for this purposes

[Redcoinn]

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

[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.

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.

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.

[whanau]

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

[albert0bsd]

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!

[whanau]

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. 

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

[citb0in]

puzzles are within 1-160bit. There is no puzzle to look for in 160-256bit range so you can reduce your search to 160bit range.

RipeMD-160 bit

[GR Sasa]

puzzles are within 1-160bit. There is no puzzle to look for in 160-256bit range so you can reduce your search to 160bit range.

Wrong.

Puzzles are within 1-256bits, don't forget that he is mentioning the word Lottery, so he should be probably trying to randomly bruteforce some old shit dead 256bit key, probably a key from Satoshis keys with BSGS, and it should obviously be in the 256 bits range, thats why he called it as "puzzle256".

Ofc the chances are unbelieveably low, but it still counts as a Lottery as he said.

Alberto, What are your thougts?

[citb0in]

puzzles are within 1-160bit. There is no puzzle to look for in 160-256bit range so you can reduce your search to 160bit range.

Wrong.

Puzzles are within 1-256bits, don't forget that he is mentioning the word Lottery, so he should be probably trying to randomly bruteforce some old shit dead 256bit key, probably a key from Satoshis keys with BSGS, and it should obviously be in the 256 bits range, thats why he called it as "puzzle256".

Ofc the chances are unbelieveably low, but it still counts as a Lottery as he said.

Alberto, What are your thougts?

@GR Sasa: you should go ahead and read the nature of Bitcoin addresses. Bitcoin addresses have the security of 2^160 and that is due to the RIPE-MD 160 hash algorithm being involved. Therefore the creator of the puzzle moved at 11th July 2017 all funds from the initially created puzzles 161-256 to the puzzles 1-160. Before transferring those amounts he informed and posted here on bitcointalk forum.

There are no puzzles 161-256 to solve. Your reward is 0.00

[digaran]

Rmd-160 hash security is 80 bits AFAIK. IDK though, I might be wrong.  Isn't keyhunt the same as any other brute force application when it comes to addresses/rmd160 hashes?  I just can't understand the speed rates posted on this thread, peta keys/s , exa keys /s? I mean with exa keys/s per 1 PC, one could use 500 PCs with some extra EC math tricks to grind several puzzles in a month.  Either nobody is able to properly use these tricks, or those capable are not aware of such tricks.

[albert0bsd]

Rmd-160 hash security is 80 bits AFAIK.

Firstly, yes, there is some truth to the idea that address collisions can happen, but it's not quite as straightforward as it may seem. Let's through the lens of the Birthday Paradox.

According to Birthday paradox is possible to find a collision aproximatly near the first squared_root of (2^160),  Now, that might sound like a lot, and it is! But here's the twist – this collision could involve any address with or without any cryptocurrency balance. To really make this work, you'd need a substantial log or database of the previous 2^80 addresses.

Now, you might be wondering about the likelihood of this collision involving some famous wallet addresses like '1Feex...' or '11111...'. Well, it's incredibly unlikely.

[GR Sasa]

creator of the puzzle moved at 11th July 2017 all funds[/url] from the initially created puzzles 161-256 to the puzzles 1-160. Before transferring those amounts he informed and posted here on bitcointalk forum.

That is correct, that he moved the funds from 161-256 to 1-160, but I'm sorry to disappoint you, but you are still wrong.

The guy meant that he is solving a key from 256 bits, meaning its the old dead key..

[citb0in]