Bitcoin puzzle transaction ~32 BTC prize to who solves it

[WanderingPhilospher]

snip

snip

McD, ktimesg and Bram, you all are arguing over doing the same thing in different ways lol.

McD has changed the way his script, or at least his thought process of how the script should work, versus his initial draft.

There could be the possibility that a 10 matching h160 is right next to another one, but of all the data I have sifted through, it never has happened. It's easy to run a decent sized range, say 2^48, where on average, you would find, 256 10 leading h160 matches, but none of them will be right beside each other. Or you can sift through Bram's PoWs and you will find, none of them are right beside each other either.

So there is nothing wrong with what McD is suggesting. You find x amount prefix, pad it by y amount on both sides (+/-) and keep on trucking until z amount of range is filled up. If key is not found, you shrink all of your previously stored padded ranges by x amount, and search again. The key would eventually be found, just as if you did large range searches, randomly or sequentially, throughout the whole range. Brute forcing an entire range says the magic key will be found on avg, at or around 50% of total range keys searched. That's an average, could be at 1% or 99.99%. The last 2 keys were found between 51-57% via large range searches, selected randomly. There is no way of knowing which is better/faster, as it depends on which key was found and padded, close to the actual key we are searching for.

For me, I would and have tweaked the way McD script/plan works. Instead of just finding random prefixes 100% of the time, you swap over to filling the gaps, with 100% of keys. So if one padded range ends with 0x...12345, then I brute force keys starting at 0x...12346 to however large a range size you want to chew up. I have the padded ranges and the complete search ranges marked differently in the db, so if I need to shrink the padded ranges, I will only shrink those and not the 100% searched ranges.

Now, for what Bibli is doing, I am not 100% sure. I know he finds a prefix and with some calculations, makes a jump and searches for the next. But in this manner you could skip over the actual key. But I am not sure how you would go back and check the gaps you skipped unless you tracked start and end ranges and jump sizes, and then go back in and have to manually fill in those gaps if key isn't found. My issue with this, is you could find a 14 h160 match in 0xF range and spend a lot of time in that range when the actual key could be in the 0x8 range. But I do not know all of the ends and outs of his plan/thought process so I can't speak on it 100%.

[kTimesG]

There could be the possibility that a 10 matching h160 is right next to another one, but of all the data I have sifted through, it never has happened. It's easy to run a decent sized range, say 2^48, where on average, you would find, 256 10 leading h160 matches, but none of them will be right beside each other. Or you can sift through Bram's PoWs and you will find, none of them are right beside each other either.

Did it ever happen that the very next key, the one at which you jumped at, wherever that was, matched?

The chances of THAT happening, is equal to the chance of having the adjacent key matching.

Same question: if you have a minimum interval found in the PoW of Bram's, and use that as a gap fill: do you find, on average, at least one match in the first "minimum interval size" keys starting from where you jumped? Aren't the chances the same, except you changed the point of reference?...

Or do you believe that this changes anything in regard of finding more matches, outside the gaps? Or doing less work in total? Or is it more work?

I guess at Puzzle 117, the discussion will be "but there are no 2 consecutive keys matching 11 characters". Because there's likely to be two that have a common 10-char prefix. And so on.

No one is counting the gazillion consecutive keys that have common shorter prefixes. Why? Because the average length of a common prefix between two hashes is (0.5 + 0.25 + 0.125 + ... 2**-160) bits. That's less than one bit. Check it out on any range you'd like. And that would break their perception.

[WanderingPhilospher]

Or do you believe that this changes anything in regard of finding more matches, outside the gaps? Or doing less work in total? Or is it more work?

I haven't seen any one say it would be faster or less work, if they did, I missed that part.

No, it does not guarantee any speedups or less work. Anyone who says that, is wrong, IMO.

Same question: if you have a minimum interval found in the PoW of Bram's, and use that as a gap fill

I did not use gap fill on any of Bram's work. The gap fill came to me while building up a real live db for 68.

Averages and probabilities, that was my main intent. I think y'all are saying the same thing lol.

The same probability/averages that McD is talking about are the same that led Bram to come up with his PoW method, to show that work was actually being done, to his investors. On average, each subrange he ran should have produced 1,024 PoW keys. Sometimes it was more, sometimes it was less. Or now will some one say, but there could have been 3,232 keys in a subrange. Sure, but there wasn't.

Again, I do not think either way is faster or slower. Some may say but you are wasting time gathering the initial prefixes to pad them. Maybe. But I would say that when you search in subranges, you are wasting time checking some private keys in there. Example, The first 56 bit subrange of 68 would be:
0x80000000000000000
0x80100000000000000

which means you would check these keys:
0x80000000000000000
0x80000100000000000

In which any of the keys, for the challenge we are discussing, would never be in a range like that. With the new keys found since I last checked, I would have to check again, but there was only one key that had 3 same characters in a row, and it was buried at the end: 0x35C0D7234DF7DEB0F20CF7062444
So I doubt a key would ever start with 4 matching characters. Can a key, yes. In this puzzle/challenge, no. I think human eyes would have intervened there, and changed it lol.

Could you not search it and miss the key, sure, but doubtful, but it is always easy to run those if all the other options were exhausted.

[nomachine]

What is the problem with compiling on Windows?

I created a Makefile that works on both Windows and Linux.

Install MinGW-w64:

https://sourceforge.net/projects/mingw-w64/

During installation:

Set the Architecture to x86_64 (for 64-bit).

Set the Threads to posix.

Set the Exception to seh.

The Makefile automatically detects the operating system and adjusts the compiler settings accordingly.

If you're still unsure, here's the link to the releases:
https://github.com/NoMachine1/Cyclone/releases

I prefer not to deal with .exe files directly.

[zahid888]

Per core, I'm getting 4.8 MK/s with single Base58 address… Maybe that's close to Hash160 speed. @Nomachine, may i know the speed of a single core with Hash160?

[nomachine]

Per core, I'm getting 4.8 MK/s with single Base58 address… Maybe that's close to Hash160 speed. @Nomachine, may i know the speed of a single core with Hash160?

It depends on the machine and processor, as well as how the operating system is configured. The performance is very close.

On the machines I use, it ranges from 4 to 6 MK/s.

With _mm256, you can compute 8 SHA-256 hashes in parallel.
With _mm512, you can compute 16 SHA-256 hashes in parallel.

Similarly, with _mm256, you can compute 8 RIPEMD-160 operations in parallel.
With _mm512, you can compute 16 RIPEMD-160 operations in parallel.

Therefore, if you use _mm512 (and have a compatible processor for it), the speed can reach up to 12 MK/s per core

[Akito S. M. Hosana]

Therefore, if you use _mm512 (and have a compatible processor for it), the speed can reach up to 12 MK/s per core

So, you use enterprise processors like AMD EPYC to handle AVX-512?   

[nomachine]

Therefore, if you use _mm512 (and have a compatible processor for it), the speed can reach up to 12 MK/s per core

So, you use enterprise processors like AMD EPYC to handle AVX-512?   

Why do you care what I use? Planning to build a competing setup in your garage?   

[Akito S. M. Hosana]

How can I add a GPU folder to the Cyclone app and compile SECP256K1 to work on the GPU? 

[pbies]

How can I add a GPU folder to the Cyclone app and compile SECP256K1 to work on the GPU? 

Ask ChatGPT for code.

[Denevron]

How can I add a GPU folder to the Cyclone app and compile SECP256K1 to work on the GPU? 

Ask ChatGPT for code.

You will communicate with her for a very long time in order for her to do this.

[pbies]

Two prompts:

Code:

#include <stdio.h>
#include <stdint.h>
#include <cuda_runtime.h>

// Parametry krzywej SECP256K1
__device__ const uint64_t P = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F; // Modulo
__device__ const uint64_t A = 0;  // Współczynnik A krzywej eliptycznej
__device__ const uint64_t B = 7;  // Współczynnik B krzywej eliptycznej
__device__ const uint64_t GX = 0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798; // Generator X
__device__ const uint64_t GY = 0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8; // Generator Y

// Struktura punktu na krzywej
struct Point {
    uint64_t x, y;
};

// Dodawanie dwóch punktów na krzywej (mod P)
__device__ Point ecc_add(Point P1, Point P2) {
    if (P1.x == 0 && P1.y == 0) return P2;
    if (P2.x == 0 && P2.y == 0) return P1;
   
    uint64_t lambda = (P2.y - P1.y) * (P2.x - P1.x) % P;
    uint64_t x3 = (lambda * lambda - P1.x - P2.x) % P;
    uint64_t y3 = (lambda * (P1.x - x3) - P1.y) % P;

    return {x3, y3};
}

// Podwajanie punktu
__device__ Point ecc_double(Point P) {
    uint64_t lambda = (3 * P.x * P.x + A) * (2 * P.y) % P;
    uint64_t x3 = (lambda * lambda - 2 * P.x) % P;
    uint64_t y3 = (lambda * (P.x - x3) - P.y) % P;

    return {x3, y3};
}

// Mnożenie skalarne: skalar * punkt G
__device__ Point scalar_mult(uint64_t k, Point P) {
    Point R = {0, 0};  // Punkt w nieskończoności
    Point base = P;

    while (k) {
        if (k & 1) {
            R = ecc_add(R, base);
        }
        base = ecc_double(base);
        k >>= 1;
    }
    return R;
}

// Kernel CUDA do mnożenia skalarnego
__global__ void ecc_kernel(uint64_t *scalars, Point *results, int count) {
    int idx = blockIdx.x * blockDim.x + threadIdx.x;
    if (idx < count) {
        Point G = {GX, GY};
        results[idx] = scalar_mult(scalars[idx], G);
    }
}

// Host code
int main() {
    const int N = 1024;
    uint64_t scalars[N];
    Point results[N];

    // Przygotowanie danych
    for (int i = 0; i < N; i++) {
        scalars[i] = i + 1; // Przykładowe skalary
    }

    // Alokacja pamięci GPU
    uint64_t *d_scalars;
    Point *d_results;
    cudaMalloc(&d_scalars, N * sizeof(uint64_t));
    cudaMalloc(&d_results, N * sizeof(Point));

    // Kopiowanie danych na GPU
    cudaMemcpy(d_scalars, scalars, N * sizeof(uint64_t), cudaMemcpyHostToDevice);

    // Uruchomienie kernela CUDA
    ecc_kernel<<<N/256, 256>>>(d_scalars, d_results, N);

    // Kopiowanie wyników z GPU
    cudaMemcpy(results, d_results, N * sizeof(Point), cudaMemcpyDeviceToHost);

    // Zwolnienie pamięci
    cudaFree(d_scalars);
    cudaFree(d_results);

    // Wypisanie pierwszego wyniku
    printf("x: %llu, y: %llu\n", results[0].x, results[0].y);

    return 0;
}

[cctv5go]

Do you want to exchange address prefixes?1MVDYgVaSN6iKJMdVvjz5EEm7Vb6Hvpygo
target:1MVDYgVaSN6iKKEsbzRUAYFrYJadLYZvvZ

[WanderingPhilospher]

Do you want to exchange address prefixes?1MVDYgVaSN6iKJMdVvjz5EEm7Vb6Hvpygo
target:1MVDYgVaSN6iKKEsbzRUAYFrYJadLYZvvZ

Are you sure that is in the 68 bit range??

[Akito S. M. Hosana]

How can I add a GPU folder to the Cyclone app and compile SECP256K1 to work on the GPU? 

Ask ChatGPT for code.

I asked him, and he said the least pain in the ass option would be to reverse engineer VanitySearch-CUDA, Kangaroo, or KeyHunt-CUDA and then build AVX-256 around it instead of using the internal SSE implementation.

I mean, I eat poorly—just ramen—and don’t have the money to buy a $10K processor like those Digaran guys from the Pentagon and NASA. 

[nomachine]

I eat poorly—just ramen...

Go fishing, catch fish, and eat fish all day long. What else do normal Japanese people do? 

[kTimesG]

How can I add a GPU folder to the Cyclone app and compile SECP256K1 to work on the GPU? 

Ask ChatGPT for code.

I asked him, and he said the least pain in the ass option would be to reverse engineer VanitySearch-CUDA, Kangaroo, or KeyHunt-CUDA and then build AVX-256 around it instead of using the internal SSE implementation.

WTF? Why reverse engineer something that is open source in the first place?

AVX and SSE are processor extensions. Those do not exist on a CUDA device, and code that uses CPU-specific features will not even compile, since those instructions do not exist (and they don't need to exist, honestly). I'm not sure what you are trying to do.

[Ovixx]

https://www.talkimg.com/images/2025/03/19/0DvP3.gif

Per core, I'm getting 4.8 MK/s with single Base58 address… Maybe that's close to Hash160 speed. @Nomachine, may i know the speed of a single core with Hash160?

Interesting your executable! I would like to test it. Have you published it somewhere, or you don't want to share it?

[dastic]

Code:

[13:53:46] Starting Kangaroo search
[13:53:46] Private key found: 19996463086597
[13:53:46] Starting Kangaroo search
[13:53:46] Key verified successfully!
[13:53:46] Key saved to found_key.txt
[13:53:46] Time taken: 0 hours 0 minutes 1 seconds

My python kangaroo with a twist can solve puzzle 45 in 1 second 

[kTimesG]

Code:

[13:53:46] Starting Kangaroo search
[13:53:46] Private key found: 19996463086597
[13:53:46] Starting Kangaroo search
[13:53:46] Key verified successfully!
[13:53:46] Key saved to found_key.txt
[13:53:46] Time taken: 0 hours 0 minutes 1 seconds

My python kangaroo with a twist can solve puzzle 45 in 1 second  

2**23 jumps = 8 million point additions. So maybe the twist is simply to do the arithmetic in C and call it from Python? Should take about half a second, start to finish, to solve any 44 bit private key from scratch. Now think, how long does it take to solve puzzle 80, from scratch?

Per core, I'm getting 4.8 MK/s with single Base58 address… Maybe that's close to Hash160 speed. @Nomachine, may i know the speed of a single core with Hash160?

4.8 MK/s per core, on a CPU, to do RIPEMD160(SHA256(...)) is pretty impressive. But even running the hashing on an empty buffer in a loop (no EC involved at all, simply hashing) is much slower than the actual EC throughput (12 MK to maybe 20 MK/s per core, using libsecp256k1), so it is futile to optimize that part until the hashing speed itself catches up. Currently, that means that H160 needs a 3x to 4x boost up in speed, which I find unlikely to ever happen (if it does, most likely the EC throughput would also be boosted  up proportionally).