saatoshi_falling
Newbie

Activity: 21
Merit: 0
|
 |
March 17, 2025, 10:35:22 AM |
|
nomachine any chance you can also release a compiled version for noobs like me to run it as well?
|
|
|
|
|
|
nomachine
|
 |
March 17, 2025, 11:45:14 AM |
|
nomachine any chance you can also release a compiled version for noobs like me to run it as well?
The compiled Cyclone is located inside the ZIP archive available here: https://github.com/NoMachine1/Cyclone/releases/
|
BTC: bc1qdwnxr7s08xwelpjy3cc52rrxg63xsmagv50fa8
|
|
|
Akito S. M. Hosana
Jr. Member

Activity: 462
Merit: 8
|
 |
March 17, 2025, 11:49:50 AM |
|
I noticed some screen flickering in the app. Could you check if there's a way to fix it? 
|
|
|
|
|
|
nomachine
|
 |
March 17, 2025, 11:54:14 AM |
|
I noticed some screen flickering in the app. Could you check if there's a way to fix it?  I've already done it. The new version has been updated in Git. 
|
BTC: bc1qdwnxr7s08xwelpjy3cc52rrxg63xsmagv50fa8
|
|
|
fecell
Jr. Member

Activity: 186
Merit: 2
|
 |
March 17, 2025, 12:13:01 PM |
|
Create bruteforce with one prism, one laser, and 256 detectors... hardware... The minimal change in lasers's spectrum decomposes through a prism differently. Maybe something will work out.  Each detector is one bit, so with light's speed can be bruteforced all. Next step is secp256k1 optical realisation.
|
|
|
|
|
|
nomachine
|
 |
March 17, 2025, 12:20:20 PM |
|
Create bruteforce with one prism, one laser, and 256 detectors... hardware... The minimal change in lasers's spectrum decomposes through a prism differently. Maybe something will work out.  Each detector is one bit, so with light's speed can be bruteforced all. Next step is secp256k1 optical realisation. A special laboratory is needed for such a computer. Not to mention that laser generated (radiated) random numbers are needed combined with a quantum computer. And such a quantum computer must have a special kind of qubit for Shor's algorithm, special efficiency power supplies, sub-zero cooling and a fully controlled environment.
|
BTC: bc1qdwnxr7s08xwelpjy3cc52rrxg63xsmagv50fa8
|
|
|
MrGPBit
Jr. Member

Activity: 55
Merit: 1
|
 |
March 17, 2025, 12:34:11 PM |
|
Can you specify that not all CPU cores are used, but rather that 6 cores are used with a command, for example with -t 6?
|
|
|
|
|
saatoshi_falling
Newbie

Activity: 21
Merit: 0
|
 |
March 17, 2025, 12:45:18 PM |
|
Thanks, but I guess I can't run it, It gave about x4 .dll missing errors, each one I downloaded and added to the same folder, and then it said "The application was unable to start correctly (0xc0000007b). Click OK to close the application. I will perhaps check back a week or so and try to download it again.
|
|
|
|
|
dastic
Jr. Member

Activity: 35
Merit: 1
|
 |
March 17, 2025, 01:02:42 PM |
|
Thanks, but I guess I can't run it, It gave about x4 .dll missing errors, each one I downloaded and added to the same folder, and then it said "The application was unable to start correctly (0xc0000007b). Click OK to close the application. I will perhaps check back a week or so and try to download it again. You need to run it from the CMD or powershell... hold SHIFT and right click anywhere in the folder where you have the .exe and then "Open Terminal" then you can run it by typing: ./Cyclone -h <hash160_hex> -p -b <prefix_length> -R For puzzle 68 - ./Cyclone -h e0b8a2baee1b77fc703455f39d51477451fc8cfc -p 68 -b 8 -R
|
|
|
|
|
HABJo12
Newbie

Activity: 23
Merit: 0
|
 |
March 17, 2025, 01:03:39 PM |
|
Most of the application posted here are whether they are not full or they are samples no one is going to pass the probabilities chance of getting the prize for anyone for example the last applications are meant to solve puzzle 68 but the bit it can solve is limited to 1 up to 20 (Puzzle 68 is 68 bits) so most of the coders here is playing on you work on your own Guys
|
|
|
|
|
Desyationer
Jr. Member

Activity: 64
Merit: 2
|
 |
March 17, 2025, 01:07:24 PM |
|
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
|
|
|
|
|
|
nomachine
|
 |
March 17, 2025, 01:08:50 PM Last edit: March 17, 2025, 01:23:37 PM by nomachine |
|
I will perhaps check back a week or so and try to download it again.
I don't have Windows on any of my machines. You'll be waiting a long time if you wait for me.  Can you specify that not all CPU cores are used, but rather that 6 cores are used with a command, for example with -t 6?
Done.
|
BTC: bc1qdwnxr7s08xwelpjy3cc52rrxg63xsmagv50fa8
|
|
|
|
kTimesG
|
 |
March 17, 2025, 01:24:56 PM |
|
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 They don't. But if you want some prefix, than H160 might have a prefix that looks good, but is below (or above) the min/max addresses that have the given prefix. This is also the main reason why it's totally stupid to search for the address prefix - the H160 may have more or less actual exact bits then desired. Do you also honestly think no one ever discovered that it's the H160, not the address (or some stupid prefix non-sense) that matters in reality? 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).
|
|
|
|
Desyationer
Jr. Member

Activity: 64
Merit: 2
|
 |
March 17, 2025, 01:52:39 PM |
|
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.
|
|
|
|
|
|
mcdouglasx
|
 |
March 17, 2025, 04:06:05 PM |
|
FUD,FUD and FUD
Yeah, we all already know that you don’t support the idea of searching for prefixes, and I think most of us here know that it’s difficult to find the target. However, we do something, even if to you it seems like a waste of time; for others, it’s an opportunity to learn things, regardless of the outcome.
|
|
|
|
|
kTimesG
|
 |
March 17, 2025, 04:25:12 PM |
|
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.
The reason why 4090 is fast is because it consumes more power. Forget about specs, you can directly compare two cards depending on how much power each one eats up - all of them in the last few gens will have more or less the same hash-rate / watt. So don't expect an RTX 4090 that's in 50% load to run faster than a card that's spec'ed at half the power draw but runs at 100% and doesn't have cooling issues. For puzzle solvers, H160 is extracted from address, in order to account for the network byte, or/and probably left-overs from vanity search prefix-based programs. Pretty-sure they all match H160, it's useless to do base58 conversions if the H160 check fast-fails first. FUD,FUD and FUD
Yeah, we all already know that you don’t support the idea of searching for prefixes, and I think most of us here know that it’s difficult to find the target. However, we do something, even if to you it seems like a waste of time; for others, it’s an opportunity to learn things, regardless of the outcome. Yeah, an opportunity to learn the hard way that it was a waste of time matching some base58 characters to a H160 that might be shorter or longer than the H160 of the address that is being searched. And a waste of time skipping H160s that DID start with the intended prefix, but don't decode back to the searched address prefix. 
|
|
|
|
0x1FFFFFF
Newbie

Activity: 9
Merit: 0
|
 |
March 17, 2025, 06:35:31 PM |
|
There is no end to the keyspace in my script! It runs in full random mode, creating an endless loop.
Hi @Nomachine. I am curious about random mode in this code. is that the random totally fully random each keys or it similiar like keyhunt ? Thanks.
|
|
|
|
|
|
nomachine
|
 |
March 17, 2025, 07:03:18 PM |
|
Hi @Nomachine. I am curious about random mode in this code. is that the random totally fully random each keys or it similiar like keyhunt ?
The "random mode" is designed to generate private keys within a specified range using a pseudo-random number generator (PRNG). Specifically, it employs the Xoshiro256plus PRNG, a high-quality random number generator known for its speed. Int generateRandomPrivateKey(Int minKey, Int range, Xoshiro256plus &rng) { Int randomPrivateKey((uint64_t)0);
// Generate random values in chunks of 64 bits using Xoshiro256plus for (int i = 0; i < NB64BLOCK; ++i) { uint64_t randVal = rng.next(); randomPrivateKey.ShiftL(64); // Shift left by 64 bits randomPrivateKey.Add(randVal); }
// Apply modulo operation and add minKey randomPrivateKey.Mod(&range); randomPrivateKey.Add(&minKey);
return randomPrivateKey; }The random keys are generated within a specific range defined by minKey and maxKey. These values are derived from the puzzle number or the provided range (via the -r argument or -p). The generateRandomPrivateKey function ensures that the generated keys fall within this range by applying a modulo operation and adding minKey. while (!matchFound) { Int currentBatchKey; if (randomMode) { // Generate a random private key within the thread's range using Xoshiro256plus currentBatchKey = generateRandomPrivateKey(minKey, range, rng); } else { // Sequential mode if (intGreater(privateKey, threadRangeEnd)) { break; } currentBatchKey.Set(&privateKey); }Each thread initializes its own instance of the Xoshiro256plus PRNG with a unique seed. This ensures that the random sequences generated by different threads do not overlap and remain independent of one another. // PARRALEL COMPUTING BLOCK #pragma omp parallel num_threads(numThreads) \ shared(globalComparedCount, globalElapsedTime, mkeysPerSec, matchFound, \ foundPrivateKeyHex, foundPublicKeyHex, lastStatusTime, lastSaveTime, g_progressSaveCount, \ g_threadPrivateKeys) { const int threadId = omp_get_thread_num();
// Initialize Xoshiro256plus PRNG for this thread Xoshiro256plus rng(std::chrono::steady_clock::now().time_since_epoch().count() + threadId);
Int privateKey = hexToInt(g_threadRanges[threadId].startHex); const Int threadRangeEnd = hexToInt(g_threadRanges[threadId].endHex);
#pragma omp critical { g_threadPrivateKeys[threadId] = padHexTo64(intToHex(privateKey)); } The keys are distributed uniformly across the range. Therefore, this process is entirely random, consistent with the approach I always use in all my scripts.
|
BTC: bc1qdwnxr7s08xwelpjy3cc52rrxg63xsmagv50fa8
|
|
|
btc11235
Jr. Member

Activity: 35
Merit: 1
|
 |
March 17, 2025, 07:25:21 PM |
|
@nomachine Yeah, your copy of that repo really needs to have a copy of the original license (with copyright/attribution) in order to be compliant with the licensing agreement... Easy to forget when you're only dealing with a portion of the original code (looks like just the AVX2 folder, and the license file is at the root), but still necessary... Of course. Here you go. https://github.com/NoMachine1/Cycloneyou're awesome 
|
|
|
|
|
Akito S. M. Hosana
Jr. Member

Activity: 462
Merit: 8
|
 |
March 17, 2025, 07:36:39 PM |
|
Xoshiro256plus PRNG, a high-quality random number generator known for its speed.
Where is the bottleneck in this script, essentially? How can we speed it up further? 
|
|
|
|
|
|