Bsgs is now holding 18 exa keys/s stable.
Running a program to searches 18 exa keys/s is impressive!
I have 16 GB and Core i7, and get only 70 Peta key/s
Topic: Keyhunt - development requests - bug reports - page 6. (Read 11445 times)
Running a program to searches 18 exa keys/s is impressive!
I have 16 GB and Core i7, and get only 70 Peta key/s
I figured it out. But not sure what was going on. I reinstalled ubuntu from usb, started fresh. Bsgs is now holding 18 exa keys/s stable. All 80 cpu threads loaded around 50-60 percent. Appears my ram can now not keep up. But the speed drop out is gone.
Uhmm, I think that 40 is the limit 
If you see the processor specifications on https://ark.intel.com/content/www/us/en/ark/products/120489/intel-xeon-gold-6148-processor-27-5m-cache-2-40-ghz.html
It is 20 cores so it it's only 40 threads max.
I am not hardware expert so if you believe that your processor can be overclocked or something like that I think that you should search about it on a Hardware forum or something like that.
If you see the processor specifications on https://ark.intel.com/content/www/us/en/ark/products/120489/intel-xeon-gold-6148-processor-27-5m-cache-2-40-ghz.html
It is 20 cores so it it's only 40 threads max.
I am not hardware expert so if you believe that your processor can be overclocked or something like that I think that you should search about it on a Hardware forum or something like that.
2 cpus at 40 threads, 80 total. CPU info shows 80 possible. Ubuntu shows 80 threads. But you may be correct. Strange as bios reports 40 however its not clear if its reporting for 1 cpu or 2.
Again thank you for all the hard work!
Uhmm, I think that 40 is the limit
If you see the processor specifications on https://ark.intel.com/content/www/us/en/ark/products/120489/intel-xeon-gold-6148-processor-27-5m-cache-2-40-ghz.html
It is 20 cores so it it's only 40 threads max.
I am not hardware expert so if you believe that your processor can be overclocked or something like that I think that you should search about it on a Hardware forum or something like that.
If you see the processor specifications on https://ark.intel.com/content/www/us/en/ark/products/120489/intel-xeon-gold-6148-processor-27-5m-cache-2-40-ghz.html
It is 20 cores so it it's only 40 threads max.
I am not hardware expert so if you believe that your processor can be overclocked or something like that I think that you should search about it on a Hardware forum or something like that.
Maybe it is something related to the Operating system thread administration. Can you try some 78 or 79 threads instead?
Maybe the CPU gets heater and it reduce the frequency. Check first running it with less than 80 thread try some 70, 75... Just to discard some cases.
Maybe the CPU gets heater and it reduce the frequency. Check first running it with less than 80 thread try some 70, 75... Just to discard some cases.
Ubuntu 23.04
I have tried 78, 50, 55 all the same results. Anything over 40 decreases the speed by half with twice the threads. Maybe a Kernel issue?
Maybe it is something related to the Operating system thread administration. Can you try some 78 or 79 threads instead?
Maybe the CPU gets heater and it reduce the frequency. Check first running it with less than 80 thread try some 70, 75... Just to discard some cases.
Maybe the CPU gets heater and it reduce the frequency. Check first running it with less than 80 thread try some 70, 75... Just to discard some cases.
BSGS Dual CPU support? Running 2x intel gold 6148 40 threads each 256gig ram.
At 40 threads I get 15 Exa keys/s
At 80 threads I get 6-12 Exa keys/s
All threads are fully loaded when 80 is requested. Bottle neck somewhere?
I am still fine with 40, but 80 would be nice.
Thank you for all the great work Alberto!
At 40 threads I get 15 Exa keys/s
At 80 threads I get 6-12 Exa keys/s
All threads are fully loaded when 80 is requested. Bottle neck somewhere?
I am still fine with 40, but 80 would be nice.
Thank you for all the great work Alberto!
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..
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.
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.
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
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?
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
RipeMD-160 bit
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
>>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
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.
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!
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.
Thanks for an excellent program
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
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.
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
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
Jump to: