Search content
Sort by
Showing 20 of 88 results by Desyationer
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
It seems I managed to run wifhunter on win11, 5800x3d shows the following speed, it is interesting to compare with other processors.
Code:
[2025-04-18 16:00:55] [I] Starting scan for prefix: L5FNHG
[2025-04-18 16:00:55] [I] WIF Hunter
[2025-04-18 16:00:55] [I] CHECKING WIF PREFIX KwDiBf:
[2025-04-18 16:01:06] [I] Progress = 0.43 % [16.26 Mkeys/sec]
[2025-04-18 16:01:18] [I] Progress = 0.86 % [16.24 Mkeys/sec]
[2025-04-18 16:01:30] [I] Progress = 1.29 % [14.86 Mkeys/sec]
[2025-04-18 16:01:41] [I] Progress = 1.72 % [15.50 Mkeys/sec]
[2025-04-18 16:01:53] [I] Progress = 2.16 % [15.08 Mkeys/sec]
[2025-04-18 16:02:05] [I] Progress = 2.59 % [15.70 Mkeys/sec]
[2025-04-18 16:02:17] [I] Progress = 3.02 % [15.60 Mkeys/sec]
[2025-04-18 16:02:28] [I] Progress = 3.45 % [15.64 Mkeys/sec]
[2025-04-18 16:02:31] [W] KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn
Found matching private key!
[2025-04-18 16:02:31] [i] PRIVATE KEY FOUND!!!
[2025-04-18 16:02:31] Compressed HASH160: 751e76e8199196d454941c45d1b3a323f1433bd6
[2025-04-18 16:02:31] Uncompressed HASH160: 91b24bf9f5288532960ac687abb035127b1d28a5
[2025-04-18 16:02:31] Private key (hex): 0000000000000000000000000000000000000000000000000000000000000001
[2025-04-18 16:02:31] Private key (decimal): 1
[2025-04-18 16:02:31] [I] Private key saved to C:\Users\hexap\Downloads\WIFHunter-main\reports\found_key.txt
[2025-04-18 16:02:31] [i] Script execution ended
[2025-04-18 16:00:55] [I] WIF Hunter
[2025-04-18 16:00:55] [I] CHECKING WIF PREFIX KwDiBf:
[2025-04-18 16:01:06] [I] Progress = 0.43 % [16.26 Mkeys/sec]
[2025-04-18 16:01:18] [I] Progress = 0.86 % [16.24 Mkeys/sec]
[2025-04-18 16:01:30] [I] Progress = 1.29 % [14.86 Mkeys/sec]
[2025-04-18 16:01:41] [I] Progress = 1.72 % [15.50 Mkeys/sec]
[2025-04-18 16:01:53] [I] Progress = 2.16 % [15.08 Mkeys/sec]
[2025-04-18 16:02:05] [I] Progress = 2.59 % [15.70 Mkeys/sec]
[2025-04-18 16:02:17] [I] Progress = 3.02 % [15.60 Mkeys/sec]
[2025-04-18 16:02:28] [I] Progress = 3.45 % [15.64 Mkeys/sec]
[2025-04-18 16:02:31] [W] KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn
Found matching private key!
[2025-04-18 16:02:31] [i] PRIVATE KEY FOUND!!!
[2025-04-18 16:02:31] Compressed HASH160: 751e76e8199196d454941c45d1b3a323f1433bd6
[2025-04-18 16:02:31] Uncompressed HASH160: 91b24bf9f5288532960ac687abb035127b1d28a5
[2025-04-18 16:02:31] Private key (hex): 0000000000000000000000000000000000000000000000000000000000000001
[2025-04-18 16:02:31] Private key (decimal): 1
[2025-04-18 16:02:31] [I] Private key saved to C:\Users\hexap\Downloads\WIFHunter-main\reports\found_key.txt
[2025-04-18 16:02:31] [i] Script execution ended
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Could you please tell me where you live, so that I can visit you? 
Anchorage, Alaska
Are you an Eskimo?
Nope. I am of Russian descent
Very Cool, I`m too!
https://github.com/NoMachine1/WIFHunter
I successfully compiled it on win11, but now I don’t know the commands for the batch file, the bare exe file without commands immediately closes itself.
Code:
MINGW64 /c/Users/hexap/Downloads/WIFHunter-main
# make
g++ -m64 -std=c++17 -mssse3 -msse4.1 -Ofast -Wall -Wextra -funroll-loops -ftree-vectorize -fstrict-aliasing -fno-semantic-interposition -fno-exceptions -fno-rtti -flto -pthread -mavx2 -mbmi2 -madx -MMD -MP -c WIFHunter.cpp -o WIFHunter.o
g++ -m64 -std=c++17 -mssse3 -msse4.1 -Ofast -Wall -Wextra -funroll-loops -ftree-vectorize -fstrict-aliasing -fno-semantic-interposition -fno-exceptions -fno-rtti -flto -pthread -mavx2 -mbmi2 -madx -MMD -MP -c sha256_avx2.cpp -o sha256_avx2.o
g++ -m64 -std=c++17 -mssse3 -msse4.1 -Ofast -Wall -Wextra -funroll-loops -ftree-vectorize -fstrict-aliasing -fno-semantic-interposition -fno-exceptions -fno-rtti -flto -pthread -mavx2 -mbmi2 -madx WIFHunter.o sha256_avx2.o -o WIFHunter.exe -mavx2 -mbmi2 -madx -pthread -static
WIFHunter.cpp: In function 'main':
WIFHunter.cpp:292:51: warning: argument 1 value '18446744073709551615' exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=]
292 | threads_progresses = new int[threads_number]{0};
| ^
D:/msys64/mingw64/include/c++/14.2.0/new:133:26: note: in a call to allocation function 'operator new []' declared here
133 | _GLIBCXX_NODISCARD void* operator new[](std::size_t) _GLIBCXX_THROW (std::bad_alloc)
| ^
WIFHunter.cpp:291:48: warning: argument 1 value '18446744073709551615' exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=]
291 | thread* threads = new thread[threads_number];
| ^
D:/msys64/mingw64/include/c++/14.2.0/new:133:26: note: in a call to allocation function 'operator new []' declared here
133 | _GLIBCXX_NODISCARD void* operator new[](std::size_t) _GLIBCXX_THROW (std::bad_alloc)
| ^
make[1]: Entering directory '/c/Users/hexap/Downloads/WIFHunter-main'
rm -f WIFHunter.o sha256_avx2.o WIFHunter.d sha256_avx2.d
make[1]: Leaving directory '/c/Users/hexap/Downloads/WIFHunter-main'
# make
g++ -m64 -std=c++17 -mssse3 -msse4.1 -Ofast -Wall -Wextra -funroll-loops -ftree-vectorize -fstrict-aliasing -fno-semantic-interposition -fno-exceptions -fno-rtti -flto -pthread -mavx2 -mbmi2 -madx -MMD -MP -c WIFHunter.cpp -o WIFHunter.o
g++ -m64 -std=c++17 -mssse3 -msse4.1 -Ofast -Wall -Wextra -funroll-loops -ftree-vectorize -fstrict-aliasing -fno-semantic-interposition -fno-exceptions -fno-rtti -flto -pthread -mavx2 -mbmi2 -madx -MMD -MP -c sha256_avx2.cpp -o sha256_avx2.o
g++ -m64 -std=c++17 -mssse3 -msse4.1 -Ofast -Wall -Wextra -funroll-loops -ftree-vectorize -fstrict-aliasing -fno-semantic-interposition -fno-exceptions -fno-rtti -flto -pthread -mavx2 -mbmi2 -madx WIFHunter.o sha256_avx2.o -o WIFHunter.exe -mavx2 -mbmi2 -madx -pthread -static
WIFHunter.cpp: In function 'main':
WIFHunter.cpp:292:51: warning: argument 1 value '18446744073709551615' exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=]
292 | threads_progresses = new int[threads_number]{0};
| ^
D:/msys64/mingw64/include/c++/14.2.0/new:133:26: note: in a call to allocation function 'operator new []' declared here
133 | _GLIBCXX_NODISCARD void* operator new[](std::size_t) _GLIBCXX_THROW (std::bad_alloc)
| ^
WIFHunter.cpp:291:48: warning: argument 1 value '18446744073709551615' exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=]
291 | thread* threads = new thread[threads_number];
| ^
D:/msys64/mingw64/include/c++/14.2.0/new:133:26: note: in a call to allocation function 'operator new []' declared here
133 | _GLIBCXX_NODISCARD void* operator new[](std::size_t) _GLIBCXX_THROW (std::bad_alloc)
| ^
make[1]: Entering directory '/c/Users/hexap/Downloads/WIFHunter-main'
rm -f WIFHunter.o sha256_avx2.o WIFHunter.d sha256_avx2.d
make[1]: Leaving directory '/c/Users/hexap/Downloads/WIFHunter-main'
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Could you test it also on rtx4060, if you have it
I`m not have any other gpu`s
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Tests on the PALIT Omniblack RTX 4090 at various power levels show that running at 100% power offers the least efficient balance between consumption and performance. Operating at 33% power appears to be the safest and most stable option, allowing for continuous 24/7 use over several weeks without risk
I realize this might be useless information, but maybe someone will find it interesting. Personally, I'd love to see similar tests from other GPU hunters — mkeys, power usage, temperatures, and so on
Could you test it also on rtx4060, if you have itI realize this might be useless information, but maybe someone will find it interesting. Personally, I'd love to see similar tests from other GPU hunters — mkeys, power usage, temperatures, and so on
I didn't know that AI generation is a violation. It's sad because my level of English is bad, and AI allows me to translate qualitatively, unlike Google, I look like a native English speaker and not a Slav.
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
⭐ Merited by FrozenThroneGuy (2)
Tests on the PALIT Omniblack RTX 4090 at various power levels show that running at 100% power offers the least efficient balance between consumption and performance. Operating at 33% power appears to be the safest and most stable option, allowing for continuous 24/7 use over several weeks without risk
I realize this might be useless information, but maybe someone will find it interesting. Personally, I'd love to see similar tests from other GPU hunters — power usage, temperatures, and so on
I realize this might be useless information, but maybe someone will find it interesting. Personally, I'd love to see similar tests from other GPU hunters — power usage, temperatures, and so on
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
kTimesG
nomachine
Bram24732
AlanJohnson
Thanks for the clarification. It's now clear that if the CUDA algorithm achieves its high speed by computing the delta from the previous key, then applying a filter would likely be ineffective. Even a 30% reduction in the range probably wouldn't offset the performance loss caused by filtering—assuming it's even possible to implement it. On standard CPUs, filtering might be slightly more reasonable, but their speed is vastly inferior compared to GPUs. Overall, even if filtering could be perfectly implemented on a GPU without any performance drop, a 30% reduction in the key space wouldn't make much of a difference for anyone without access to thousands of GPUs. The real benefit would come not from a 30% reduction, but from reducing the range by several orders of magnitude.
nomachine
Bram24732
AlanJohnson
Thanks for the clarification. It's now clear that if the CUDA algorithm achieves its high speed by computing the delta from the previous key, then applying a filter would likely be ineffective. Even a 30% reduction in the range probably wouldn't offset the performance loss caused by filtering—assuming it's even possible to implement it. On standard CPUs, filtering might be slightly more reasonable, but their speed is vastly inferior compared to GPUs. Overall, even if filtering could be perfectly implemented on a GPU without any performance drop, a 30% reduction in the key space wouldn't make much of a difference for anyone without access to thousands of GPUs. The real benefit would come not from a 30% reduction, but from reducing the range by several orders of magnitude.
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
I'm not a programmer at all - the code I use is entirely written by AI. However, the AI couldn't give me a clear answer to my question: is it possible to iterate over private keys within a specific range while instantly filtering out "unreliable" ones, without affecting the performance of the iteration itself? Or does the CUDA architecture only support fully linear brute-force traversal with no filtering whatsoever in order to maintain optimal speed, making any on-the-fly filtering too resource-intensive due to the massive size of the range? I couldn't even implement this in Python with the help of the AI - writing a basic key iteration script is easy, but as soon as I try to apply even a simple filter, the script slows down significantly. Despite many attempts, the AI couldn't help me solve this problem.
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Yes. Theoretically, you need at least 1TB. I've never tried more than 60. Anything around 300GB is considered a baby table. I don't have time to wait for a bigger one to be generated.
Why are you publishing all the scripts from before now?
Because it's a dead end. Game over. There's no point in hiding any more scripts for the puzzles - whether they're useful or not. For Puzzle 69, you're over 2,500 GPUs. For Puzzle 71, over 3,000.
What are you guys planning to do now ? Is something similar to bitcoin puzzle out there to hunt ?
https://privatekeys.pw/puzzles/0.01-btc-corey-phillips-puzzle
https://privatekeys.pw/puzzles/gsmg-puzzle
https://privatekeys.pw/puzzles/0.03-btc-coinmonks-puzzle
https://privatekeys.pw/puzzles/0.005-btc-lvl5-puzzle
https://privatekeys.pw/puzzles/2-btc-rushwallet-puzzle
It must be pretty funny to put some BTC on an address ... then announce some stupid picture or something and tell people it's a "puzzle" when in fact it's just bullshit and they are wasting their time.
In this case, the creator's credibility plays an important role. If the puzzles were made by someone well-known, like Elon Musk, then it would be much more likely that they are genuine challenges with real solutions and a prize at the end. Otherwise, there's a risk that it's just a meaningless set of riddles with no answer or reward, designed only to mock those who try to solve them. Since the creator is anonymous, anyone could pose as such an "author" and take pleasure in watching others struggle.
Is the creator of these puzzles known?
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Why are you all so angry here? Well, people have the opportunity to use farms - it's their business. Here, no one is obliged to anyone, a person wants - he posts a program for everyone, or an idea for implementing a program, if he doesn't want - he doesn't post it, it's strictly everyone's business. On the contrary, we should be glad that there are people who manage to find the keys)
What’s there to be happy about? For 99.9% of miners without GPU farms, this means their chances have been cut in half! Well, people have the opportunity to use farms - it's their business. Here, no one is obliged to anyone, a person wants - he posts a program for everyone, or an idea for implementing a program, if he doesn't want - he doesn't post it, it's strictly everyone's business. On the contrary, we should be glad that there are people who manage to find the keys)
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
According to my theories, which were based on a kind of speculative "magic," the key wasn't even remotely close to anything starting with *bb*. In fact, the *B* range was among the least likely scenarios in my estimations. It feels like a cruel, ironic slap in the face from cryptography itself is a direct insult to all my efforts, ideas, and long hours of contemplation.
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
I compiled the exe, but it seems the program isn't working correctly. The progress goes over 100%, but the test range is not found. I'm getting around 50 million keys on the 5800X3D.
Code:
=======================================
== Mutagen Puzzle Solver by Denevron ==
=======================================
Starting puzzle: 38 (38-bit)
Target HASH160: b190e2d40c...9e7ba39364
Base Key: 0x1757756A93
Flip count: 21
Total Flips: 28781143380
Using: 16 threads
Progress: 1.146584%
Processed: 330000000
Speed: 48.02 Mkeys/s
Elapsed Time: 00:01:04
== Mutagen Puzzle Solver by Denevron ==
=======================================
Starting puzzle: 38 (38-bit)
Target HASH160: b190e2d40c...9e7ba39364
Base Key: 0x1757756A93
Flip count: 21
Total Flips: 28781143380
Using: 16 threads
Progress: 1.146584%
Processed: 330000000
Speed: 48.02 Mkeys/s
Elapsed Time: 00:01:04
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
This is truly unfortunate… Each conversion of a number into a Bitcoin address requires around 1,700 simple operations. Even if this process could be optimized to a single basic operation, brute-forcing the 68th range would still take at least six months, even on the most powerful GPUs like the RTX 4090 or 5090. As far as I know, all existing brute-force programs such as KeyHunt and BitCrack utilize only the CUDA cores of GPUs. However, there is an untapped source of power tensor cores which remain unused. The theoretical performance of CUDA cores is around ~80 TFLOPS for the RTX 4090 and ~100 TFLOPS for the RTX 5090, while tensor cores offer significantly higher performance: 285 TFLOPS for the RTX 4090 and 400 TFLOPS for the RTX 5090. If tensor cores could be utilized, the speed of brute-force calculations could be increased several times over. In theory, tensor cores are also capable of handling matrix multiplications and similar computations. Currently, the maximum speed achievable using publicly available CUDA-based programs from GitHub with an RTX 5090 is around 9GKeys per second.
Tensor cores only do 8-bit and 16-bit float ops (e.g. extremely low precision for floating point numbers). So those TFLOPS you see are relative to these kind of numbers, not 32-bit integers/floats. We'd need some Bernstein-level genius mind to help us make use of them when dealing with ECC. They can potentially be put to use to accelerate the inversion, but this requires coming up with a new inversion algorithm. Something that can work via approximations instead of exact values, to find the inverse faster.
I wasn't aware of such limitations of tensor cores—now it makes sense why they haven't been used for key enumeration yet. I'm curious, if it were possible to leverage them at least for auxiliary inversion, what theoretical speedup could be expected?
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
This is truly unfortunate… Each conversion of a number into a Bitcoin address requires around 1,700 simple operations. Even if this process could be optimized to a single basic operation, brute-forcing the 68th range would still take at least six months, even on the most powerful GPUs like the RTX 4090 or 5090. As far as I know, all existing brute-force programs such as KeyHunt and BitCrack utilize only the CUDA cores of GPUs. However, there is an untapped source of power tensor cores which remain unused. The theoretical performance of CUDA cores is around ~80 TFLOPS for the RTX 4090 and ~100 TFLOPS for the RTX 5090, while tensor cores offer significantly higher performance: 285 TFLOPS for the RTX 4090 and 400 TFLOPS for the RTX 5090. If tensor cores could be utilized, the speed of brute-force calculations could be increased several times over. In theory, tensor cores are also capable of handling matrix multiplications and similar computations. Currently, the maximum speed achievable using publicly available CUDA-based programs from GitHub with an RTX 5090 is around 9GKeys per second.
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Hello everyone. I have published my optimized versions of VanitySearch (CUDA) with speed boost in case anyone is interested 
The "bitcrack" version is specific to the puzzle and allows searching for addresses and prefixes (compressed) within a given range. The speed is about 6900 MKey/s on a 4090 and 8800 MKey/s on 5090.
The second version, on the other hand, performs a standard search for vanity addresses (not just P2PKH compressed) but with the same optimizations in terms of math and CUDA code. Random searches with endomorphisms.
https://github.com/FixedPaul/VanitySearch-Bitcrack
https://github.com/FixedPaul/VanitySearch
The "bitcrack" version is specific to the puzzle and allows searching for addresses and prefixes (compressed) within a given range. The speed is about 6900 MKey/s on a 4090 and 8800 MKey/s on 5090.
The second version, on the other hand, performs a standard search for vanity addresses (not just P2PKH compressed) but with the same optimizations in terms of math and CUDA code. Random searches with endomorphisms.
https://github.com/FixedPaul/VanitySearch-Bitcrack
https://github.com/FixedPaul/VanitySearch
Thank you for your work – it's truly impressive! The first program achieves a speed higher than any other solution I've seen. Even with a 33% power limit on an RTX 4090, it reaches around 2.3G keys per second. The second program delivers an even more record-breaking speed of about 4G keys per second under the same power limit. However, unfortunately, these impressive numbers are merely theoretical and not useful for solving puzzles, as the program does not support working with ranges.
I wonder if it is possible to implement Bitcoin address prefix searching not only by the starting characters but also by any other positions within the address. For example, searching for characters at the end, in the middle, or even a combined search where part of the characters are at the beginning, part in the middle, and part at the end, and so on.
Thanks! But why only 2.3 Gkey/s? A 4090 @300W should run at around 5.5 Gkey/s.
As for the second program, as soon as I find some time, I'll also implement search within a specific range there (without endomorphisms, of course), so that it can search within a range rather than randomly—both for prefixes and wildcards, which is what you're asking for, if I understood correctly.
2.3 Gkey/s is only about a third of my 4090’s full potential. Under full load, the speed indeed reaches around 7 Gkey/s, just as you mentioned. And the second program, which doesn’t support range searches, can actually achieve over 10 Gkey/s at full power!
However, I try not to push the GPU to its limits, as excessive heat increases wear on both the GPU and memory. My card doesn’t have liquid cooling, so I don’t see much sense in running it at maximum capacity for prolonged periods, especially for tasks like this. But when the temperature stays within safe limits, I’m comfortable letting it run key searches for many hours.
Regarding your planned program improvements—that would be absolutely fantastic! For now, I handle wildcard prefix searches using an additional filtering script in Python. This script processes the output of the main program, which searches for the first few characters but generates an overwhelming number of unnecessary results. The script intercepts this output and filters only the prefixes I’m interested in, even if they appear in different parts of the address.
Without this filtering, the main program’s result file can grow to gigabytes within minutes. However, this approach—using both the main program (such as yours) and the filtering script—introduces significant limitations on search speed, possibly due to the high-intensity data output.
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Hello everyone. I have published my optimized versions of VanitySearch (CUDA) with speed boost in case anyone is interested
The "bitcrack" version is specific to the puzzle and allows searching for addresses and prefixes (compressed) within a given range. The speed is about 6900 MKey/s on a 4090 and 8800 MKey/s on 5090.
The second version, on the other hand, performs a standard search for vanity addresses (not just P2PKH compressed) but with the same optimizations in terms of math and CUDA code. Random searches with endomorphisms.
https://github.com/FixedPaul/VanitySearch-Bitcrack
https://github.com/FixedPaul/VanitySearch
The "bitcrack" version is specific to the puzzle and allows searching for addresses and prefixes (compressed) within a given range. The speed is about 6900 MKey/s on a 4090 and 8800 MKey/s on 5090.
The second version, on the other hand, performs a standard search for vanity addresses (not just P2PKH compressed) but with the same optimizations in terms of math and CUDA code. Random searches with endomorphisms.
https://github.com/FixedPaul/VanitySearch-Bitcrack
https://github.com/FixedPaul/VanitySearch
Thank you for your work – it's truly impressive! The first program achieves a speed higher than any other solution I've seen. Even with a 33% power limit on an RTX 4090, it reaches around 2.3G keys per second. The second program delivers an even more record-breaking speed of about 4G keys per second under the same power limit. However, unfortunately, these impressive numbers are merely theoretical and not useful for solving puzzles, as the program does not support working with ranges.
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
I wonder if the Windows 11 firewall can prevent data leaks by creating a rule that blocks incoming and outgoing connections for an executable file, such as *bitcrack.exe*, in case the developer has embedded a spyware module that transmits keys and scanned ranges over the network. Or is the most reliable option to run the brute-force process on a computer completely disconnected from the internet?
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Also, did you randomly guesstimated that you can simply enumerate the keys faster (whatever that means) and straight up go from 4-5 to 5-6? On what basis? Let me tell you the truth: what you said is already done, but you probably use the wrong code or app for this, because an RTX 4090 is capable of doing 7.0 - 7.1 GK/s to scan a given range, not 4 or 5. Yes, just the keys in a given interval, not the ones with symmetry or endo (in that case, it can surpass 10 GK/s).
I wrote it that way because I never run my RTX 4090 at full power, given the extremely low chance of success. When I tested it at 100% load, both the GPU and memory heated up more than they do during gaming or even FurMark. In this mode, the 4090 could overheat and fail rather quickly.
However, I’m not a proponent of prefix-based searching—I’m simply interested in maximizing the search speed while maintaining a reasonable GPU load. Perhaps I don’t fully understand how programs like KeyHunt and BitCrack work, and the key search is already implemented using H160 rather than the full P2PKH address. However, the command in the batch file appears to be searching by the full address rather than its H160, which is why I had this question.
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Quote
And from Cyclone, we get Kangaroolone. 😄
Why do all the programs I know, such as BitCrack, KeyHunt-Cuda, and VanBitCracken, search for a single address using the full P2PKH address instead of its H160 hash? Searching by H160 could significantly speed up key enumeration—potentially increasing the rate from 4–5 GKey/s to 5–6 GKey/s for 4090
Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
Dude, you can speed up this Python code 100 times in Cyclone.
This is a pointless activity in terms of practical use, but it's still very exciting to try this code or the program called "Cyclone."