Bitcoin puzzle transaction ~32 BTC prize to who solves it

[nomachine]

But what are you going to do with it?

I need a script that can recover the beginning of a WIF where some characters are missing — for example, WIF500, etc  

https://github.com/NoMachine1/WIFHunter

There's no manual for this. If you can't figure out how it works on your own, then you don't need the script.  

this is great! Thank you.

Yeah, I wonder how many CPU cores it would take to solve a single prefix in under a minute. 128+ cores, maybe? Calculating SHA-256 checksums for each individual WIF is pretty demanding. A GPU-based WIF hunter, perhaps? 

There’s already a program like this (very fast) WifSolverCuda from our comrade @PawGo. But it works a bit differently. You need to provide a range and/or calculate a very precise stride.   

[Akito S. M. Hosana]

There’s already a program like this (very fast) WifSolverCuda from our comrade @PawGo. But it works a bit differently. You need to provide a range and/or calculate a very precise stride.   

I'll look later. Comrade? Are you a communist?

[nomachine]

There’s already a program like this (very fast) WifSolverCuda from our comrade @PawGo. But it works a bit differently. You need to provide a range and/or calculate a very precise stride.   

I'll look later. Comrade? Are you a communist?

Not quite. But I'm not far from socialist ideology and justice. First and foremost, I'm a technocrat. And a fisherman. 

[Akito S. M. Hosana]

socialist ... technocrat.

Technocratic socialism ? That doesn't exist in this world—except maybe in Finland or Sweden, where it's been practically (partially) realized, or if you live in Star Trek  

[Bram24732]

if you want a perfectly uniform distribution just replace it by a shuffled array of all numbers from 0-N.
Results will be the same.

Your script is biased in the following ways:

1- It does not use H160.

2- It loads the entire set, which means it does not take into account the computational power saved in operations on the curve, double SHA256, and RIPEMD-160 when searching statistically.

3- It does not apply a viable prefix logic.

However, here is this slightly adjusted script, using short prefixes and skipping the computational power saved in operations on the curve and double-SHA256.

It's not 100% fair for what you want in a search by prefixes since it’s implemented at half-capacity, but at least you’ll be able to verify that it’s not as useless as it might seem.

Code:

const { performance } = require("perf_hooks");
const crypto = require("crypto");

const TOTAL_SIZE = 100_000;
const RANGE_SIZE = 5_000;
const PREFIX_LENGTH = 3;
const PREFIX_THRESHOLD = 1;
const NUMBER_SIMULATIONS = 1000;
const SKIP_SIZE = Math.round(4096 * 0.3);

console.log(`
=== Configuration ===
Total numbers: ${TOTAL_SIZE.toLocaleString()}
Block size: ${RANGE_SIZE.toLocaleString()}
Prefix: ${PREFIX_LENGTH} chars (${16 ** PREFIX_LENGTH} comb.)
Skip ${SKIP_SIZE} keys per prefix match
Threshold: ${PREFIX_THRESHOLD} matches/block
Simulations: ${NUMBER_SIMULATIONS}
`);

function generateH160(data) {
  return crypto.createHash("ripemd160").update(data.toString()).digest("hex");
}

function shuffledRange(n) {
  const arr = Array.from({ length: n + 1 }, (_, i) => i);
  for (let i = arr.length - 1; i > 0; i--) {
    const j = Math.floor(Math.random() * (i + 1));
    [arr[i], arr[j]] = [arr[j], arr[i]];
  }
  return arr;
}

function sequentialRandom(totalSize, rangeSize, targetHash) {
  const numRanges = Math.floor(totalSize / rangeSize);
  const rangeOrder = shuffledRange(numRanges - 1);
  let keyChecks = 0;

  for (const blockIndex of rangeOrder) {
    const start = blockIndex * rangeSize;
    const end = (blockIndex + 1) * rangeSize;

    for (let num = start; num < end; num++) {
      const hash = generateH160(num);
      keyChecks++;
      if (hash === targetHash) return keyChecks;
    }
  }
  return keyChecks;
}

function preciseSkipSearch(totalSize, rangeSize, prefixLength, targetHash) {
  const numRanges = Math.floor(totalSize / rangeSize);
  const rangeOrder = shuffledRange(numRanges - 1);
  let keyChecks = 0;
  const targetPrefix = targetHash.substring(0, prefixLength);
  const skippedRanges = [];

  for (const blockIndex of rangeOrder) {
    const start = blockIndex * rangeSize;
    const end = (blockIndex + 1) * rangeSize;
    let prefixCount = 0;
    let current = start;

    while (current < end && prefixCount < PREFIX_THRESHOLD) {
      const hash = generateH160(current);
      keyChecks++;

      if (hash === targetHash) return keyChecks;

      if (hash.startsWith(targetPrefix)) {
        prefixCount++;
        const skipStart = current + 1;
        const skipEnd = Math.min(current + SKIP_SIZE, end);

        if (skipStart < skipEnd) {
          skippedRanges.push({ blockIndex, start: skipStart, end: skipEnd });
        }
        current = skipEnd;
      } else {
        current++;
      }
    }

    if (prefixCount >= PREFIX_THRESHOLD) {
      skippedRanges.push({
        blockIndex,
        start: current + 1,
        end: end - 1
      });
    }
  }

  const shuffledIndices = shuffledRange(skippedRanges.length - 1);
  for (const i of shuffledIndices) {
    const { start, end } = skippedRanges[i];
    for (let num = start; num <= end; num++) {
      const hash = generateH160(num);
      keyChecks++;
      if (hash === targetHash) return keyChecks;
    }
  }

  return keyChecks;
}

async function compareMethods() {
  console.log("Warm-up...");
  for (let i = 0; i < 5; i++) generateH160(i);

  const results = {
    sequential: { checks: [], times: [] },
    precise: { checks: [], times: [] }
  };

  console.log("\nStarting comparison...");
  const startTime = performance.now();

  for (let i = 0; i < NUMBER_SIMULATIONS; i++) {
    const targetNum = Math.floor(Math.random() * TOTAL_SIZE);
    const targetHash = generateH160(targetNum);

    if (i % 2 === 0) {
      const startSeq = performance.now();
      results.sequential.checks.push(sequentialRandom(TOTAL_SIZE, RANGE_SIZE, targetHash));
      results.sequential.times.push(performance.now() - startSeq);

      const startPrecise = performance.now();
      results.precise.checks.push(preciseSkipSearch(TOTAL_SIZE, RANGE_SIZE, PREFIX_LENGTH, targetHash));
      results.precise.times.push(performance.now() - startPrecise);
    } else {
      const startPrecise = performance.now();
      results.precise.checks.push(preciseSkipSearch(TOTAL_SIZE, RANGE_SIZE, PREFIX_LENGTH, targetHash));
      results.precise.times.push(performance.now() - startPrecise);

      const startSeq = performance.now();
      results.sequential.checks.push(sequentialRandom(TOTAL_SIZE, RANGE_SIZE, targetHash));
      results.sequential.times.push(performance.now() - startSeq);
    }

    if ((i + 1) % 10 === 0) console.log(`Test ${i + 1}/${NUMBER_SIMULATIONS}`);
  }

  const calculateStats = (data) => {
    const avg = data.reduce((a, b) => a + b, 0) / data.length;
    const squaredDiffs = data.map(x => Math.pow(x - avg, 2));
    const variance = squaredDiffs.reduce((a, b) => a + b, 0) / data.length;
    const stdDev = Math.sqrt(variance);
    return { avg, min: Math.min(...data), max: Math.max(...data), stdDev };
  };

  const seqStats = calculateStats(results.sequential.checks);
  const preciseStats = calculateStats(results.precise.checks);
  const seqTime = results.sequential.times.reduce((a, b) => a + b, 0) / NUMBER_SIMULATIONS;
  const preciseTime = results.precise.times.reduce((a, b) => a + b, 0) / NUMBER_SIMULATIONS;

  const improvement = ((seqStats.avg - preciseStats.avg) / seqStats.avg * 100).toFixed(2);
  const timeImprovement = ((seqTime - preciseTime) / seqTime * 100).toFixed(2);

  console.log(`
=== FINAL RESULTS ===

Random Sequential:
- Average comparisons: ${seqStats.avg.toFixed(0)}
- Average time: ${(seqTime / 1000).toFixed(3)}s
- Range: [${seqStats.min} - ${seqStats.max}]

Prefixes Search (${SKIP_SIZE} keys skip + threshold ${PREFIX_THRESHOLD}):
- Average comparisons: ${preciseStats.avg.toFixed(0)}
- Average time: ${(preciseTime / 1000).toFixed(3)}s
- Range: [${preciseStats.min} - ${preciseStats.max}]

=== CONCLUSION ===
The ${preciseStats.avg < seqStats.avg ? 'PREFIXES' : 'RANDOM+SEQUENTIAL'} method is more efficient:
- ${improvement}% fewer comparisons
- ${timeImprovement}% faster
`);

  console.log(`Total time: ${((performance.now() - startTime)/1000).toFixed(1)} seconds`);
}

compareMethods();

I'm glad we can now expand on our knowledge of math together.
Did you run your own script ? Because I did. And the results are exactly the same - no improvement over the random sequential method.

Code:

=== FINAL RESULTS ===

Random Sequential:
- Average comparisons: 49649
- Average time: 0.061s
- Range: [6 - 99990]

Prefixes Search (1229 keys skip + threshold 1):
- Average comparisons: 49905
- Average time: 0.062s
- Range: [17 - 99974]

=== CONCLUSION ===
The RANDOM+SEQUENTIAL method is more efficient:
- -0.52% fewer comparisons
- -2.23% faster

Total time: 122.9 seconds

1- It does not use H160.
3- It does not apply a viable prefix logic.

Now it does !

2- It loads the entire set, which means it does not take into account the computational power saved in operations on the curve, double SHA256, and RIPEMD-160 when searching statistically.

Should we now improve it to add EC multiply and SHA256 so that we're EXACTLY in the context you describe ?
We'll find again that prefixes have NO impact.

I'm super happy to do so if you're not yet convinced. I have all the time in the world and this will be a very good starting point next time someone comes here and talks about prefixes.
Let me also know if there is anything left that is different from the real situation, so that I do it all in one go and we dont waste time.

[kTimesG]

Should we now improve it to add EC multiply and SHA256 so that we're EXACTLY in the context you describe ?

Nah, you'd still be biased:

- it's not running in the 69 range; the immutable set is not the same....
- it's not searching for the correct prefix; I mean, birthday paradox......
- it's not finding the key as fast as it finds it once you have a million prefixes known in advance... wrong proximities calculated....
- wrong parameters; they need to be this or that so the results are better

etc...

You have too much free time

[Bram24732]

Should we now improve it to add EC multiply and SHA256 so that we're EXACTLY in the context you describe ?

Nah, you'd still be biased:

- it's not running in the 69 range; the immutable set is not the same....
- it's not searching for the correct prefix; I mean, birthday paradox......
- it's not finding the key as fast as it finds it once you have a million prefixes known in advance... wrong proximities calculated....
- wrong parameters; they need to be this or that so the results are better

etc...

You have too much free time

You have no idea. I can do this as long as I need to be
Now that we have an tangible base to work with, it's only a matter of time until we reach the empirical truth

[kTimesG]

Should we now improve it to add EC multiply and SHA256 so that we're EXACTLY in the context you describe ?

Nah, you'd still be biased:

- it's not running in the 69 range; the immutable set is not the same....
- it's not searching for the correct prefix; I mean, birthday paradox......
- it's not finding the key as fast as it finds it once you have a million prefixes known in advance... wrong proximities calculated....
- wrong parameters; they need to be this or that so the results are better

etc...

You have too much free time

You have no idea. I can do this as long as I need to be
Now that we have an tangible base to work with, it's only a matter of time until we reach the empirical truth

Are you sure about that? You'd just read the results wrong, ultimately. At which point your code is so specific, that it needs to go back to the general case. And so on.

[Akito S. M. Hosana]

a fisherman. 

Fisherman — is it possible to make a faster Base58 decoder than this? Maybe it’s a stupid question, but I don’t think this is the fastest version you give us. 

[nomachine]

a fisherman. 

Fisherman — is it possible to make a faster Base58 decoder than this? Maybe it’s a stupid question, but I don’t think this is the fastest version you give us. 

Yes, I have 8x and 16x AVX Base58 decoders—about 35MWIFs per second. But I won't be publishing them on GitHub anytime soon. 

[Bram24732]

However too (lol), in doing this and that and testing this and that, I feel like I have a better method for identifying "more than likely" ranges and the whole work distribution, than I had in the past.

P.S. If my bot says I found the key, reach out to me...LOL

P.S.S Still a lot of openings in the Beat Bram donations/crowdsourcing

Oh, man. I really hope you're not influenced by getting a few unlikely strikes sooner than expected, like your 58-bit hit last night.

Hitting the end-tail of the distribution does not mean it stays there long-term. By long-term, I don't mean scanning another 0.01%, but rather maybe long-term to the point of having chances to hit something like a 67-bit prefix.

I already gave a counter-example: I applied the prefix theory / gaps / however you want to name it over 9000 trillion keys, and the results were worse then by simply scanning sequential.

In other words: I never stumbled on a 53-bit key. More smaller-prefix lengths? Yes, indeed. But how in the world would that ever be useful for anything, except as a base for "please scan more"? Where was the "we can avoid scanning a vast amount of the search space" in my experiment? Well, probably in the skipped regions, but going over those as a backup simply means I was better off scanning in sequence, or am I missing some wisdom?

I think you have my style confused with Bibli's style.

I don't waste anytime/hashes nor skip to the "next" range and sit there until I find another one lol. The partial matches you have seen coming in...I do nothing with them. Just collect them. I've already entered all the ones I will enter for 69. We over here gap filling now lol.

To keep it simple, for now. I only collect x amount of partial h160 matches. Then I create my db and start filling in the gaps. The number is still fluid as I am trying to tweak it based on available resources (CPUs/GPUs). But for 68, I did not have the actual key buried and was right at 2^32 keys away from solving. It all comes down to firepower. If I would have had about 1,000 CPU cores and 15-20 more GPUs running for 68, I may have found it before Bram. I was walking that range in. Obviously, more fire power, the quicker it would have been.

Did you just replace range skip by range selection ?

[POD5]

Yes, I have 8x and 16x AVX Base58 decoders—about 35MWIFs per second. But I won't be publishing them on GitHub anytime soon.  

Could you please tell me where you live, so that I can visit you?  

Code:

./WIFHunter -h
[I] WIF Hunter
[E] Wrong length of WIF prefix: 2

Ok, I got it, run python script.
It uses all the available resources, getting a mark of 7 Mk/s.

[fantom06]

Yes, I have 8x and 16x AVX Base58 decoders—about 35MWIFs per second. But I won't be publishing them on GitHub anytime soon.  

Could you please tell me where you live, so that I can visit you?  

Code:

./WIFHunter -h
[I] WIF Hunter
[E] Wrong length of WIF prefix: 2

Ok, I got it, run python script.
It uses all the available resources, getting a mark of 7 Mk/s.

how did you launch it?

[Desyationer]

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'

[POD5]

how did you launch it?

By running the python script.

[fantom06]

how did you launch it?

By running the python script.

Downloads\WIFHunter-main(1)\WIFHunter-main/ice_secp256k1.dll not found
Traceback (most recent call last):
  File "---------Downloads\WIFHunter-main(1)\WIFHunter-main\WIFHunter.py", line 1, in <module>
    import secp256k1 as ice
  File "---------\Downloads\WIFHunter-main(1)\WIFHunter-main\secp256k1.py", line 94, in <module>
    ice.scalar_multiplication.argtypes = [ctypes.c_char_p, ctypes.c_char_p]   # pvk,ret
    ^^^
NameError: name 'ice' is not defined

[nomachine]

how did you launch it?

By running the python script.

Downloads\WIFHunter-main(1)\WIFHunter-main/ice_secp256k1.dll not found
Traceback (most recent call last):
  File "---------Downloads\WIFHunter-main(1)\WIFHunter-main\WIFHunter.py", line 1, in <module>
    import secp256k1 as ice
  File "---------\Downloads\WIFHunter-main(1)\WIFHunter-main\secp256k1.py", line 94, in <module>
    ice.scalar_multiplication.argtypes = [ctypes.c_char_p, ctypes.c_char_p]   # pvk,ret
    ^^^
NameError: name 'ice' is not defined

Uploaded that dll to git. Try again.

[POD5]

Downloads\WIFHunter-main(1)\WIFHunter-main/ice_secp256k1.dll not found
Traceback (most recent call last):
  File "---------Downloads\WIFHunter-main(1)\WIFHunter-main\WIFHunter.py", line 1, in <module>
    import secp256k1 as ice
  File "---------\Downloads\WIFHunter-main(1)\WIFHunter-main\secp256k1.py", line 94, in <module>
    ice.scalar_multiplication.argtypes = [ctypes.c_char_p, ctypes.c_char_p]   # pvk,ret
    ^^^
NameError: name 'ice' is not defined

You'll also need ICELAND's library

https://github.com/iceland2k14/secp256k1

[fantom06]

how did you launch it?

By running the python script.

Downloads\WIFHunter-main(1)\WIFHunter-main/ice_secp256k1.dll not found
Traceback (most recent call last):
  File "---------Downloads\WIFHunter-main(1)\WIFHunter-main\WIFHunter.py", line 1, in <module>
    import secp256k1 as ice
  File "---------\Downloads\WIFHunter-main(1)\WIFHunter-main\secp256k1.py", line 94, in <module>
    ice.scalar_multiplication.argtypes = [ctypes.c_char_p, ctypes.c_char_p]   # pvk,ret
    ^^^
NameError: name 'ice' is not defined

Uploaded that dll to git. Try again.

WIFHunter-main(1)\WIFHunter-main>python WIFHunter.py
[2025-04-18 13:43:07] Starting scan for prefix: KxGJhe
[2025-04-18 13:43:07] [E] Unexpected error: [WinError 193] %1 нe являeтcя пpилoжeниeм Win32
[2025-04-18 13:43:07] Script execution ended

[POD5]

FOK! I've been running NoMachine1's Cyclone version from 28 March because I tought it was faster than the newer ones.
After converting the privkeys to address I've found, that some wrong addresses were inbetween.
Never too late to find the right way... So, back to hunting again.

how did you launch it?

By running the python script.

Downloads\WIFHunter-main(1)\WIFHunter-main/ice_secp256k1.dll not found
Traceback (most recent call last):
  File "---------Downloads\WIFHunter-main(1)\WIFHunter-main\WIFHunter.py", line 1, in <module>
    import secp256k1 as ice
  File "---------\Downloads\WIFHunter-main(1)\WIFHunter-main\secp256k1.py", line 94, in <module>
    ice.scalar_multiplication.argtypes = [ctypes.c_char_p, ctypes.c_char_p]   # pvk,ret
    ^^^
NameError: name 'ice' is not defined

Uploaded that dll to git. Try again.

WIFHunter-main(1)\WIFHunter-main>python WIFHunter.py
[2025-04-18 13:43:07] Starting scan for prefix: KxGJhe
[2025-04-18 13:43:07] [E] Unexpected error: [WinError 193] %1 нe являeтcя пpилoжeниeм Win32
[2025-04-18 13:43:07] Script execution ended

Or use those from

https://github.com/NoMachine1/WIFHunter

[moderator's note: consecutive posts merged]