Bitcoin puzzle transaction ~32 BTC prize to who solves it

[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).

[Akito S. M. Hosana]

I don't know if anyone has done this before, but I was with a man who has the gift of remote viewing. He says the key to Puzzle 68 lies between E0000000000000000 and E0FFFFFFFFFFFFFFF. 

[mcdouglasx]

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%.

I don’t understand why they insist on declaring as false something that has all the logic of mathematics behind it, even when all the failure points of these methods have easy solutions that have already been discussed previously. What they do is focus on the worst-case scenario. It's like if I told Bram that his method fails because it could leave the winning block as random at the end; obviously, that’s something that could happen, but it’s absurd to say so because the probabilities would be too low to consider it a real problem. I think this happens when someone wants to maintain a position at all costs, even when it’s wrong.

They focus exclusively on the worst cases, which reminds me of the fallacy of composition assuming that because one part can fail under specific circumstances, the whole is defective.

[nomachine]

I don't know if anyone has done this before, but I was with a man who has the gift of remote viewing. He says the key to Puzzle 68 lies between E0000000000000000 and E0FFFFFFFFFFFFFFF. 

Oh, great, so now we’ve got to team up with Harry Potter to solve Puzzle 68 using remote viewing? Honestly, this topic has gone so far off the rails. 🎣

[Denevron]

I don't know if anyone has done this before, but I was with a man who has the gift of remote viewing. He says the key to Puzzle 68 lies between E0000000000000000 and E0FFFFFFFFFFFFFFF. 

Only this range is outside the puzzle range 68

[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?

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).

If low-level custom firmware can be developed to give us direct access to the ASIC’s SHA-256 hashing function (without its built-in mining logic), then this approach could work. We could offload the SHA-256 part to the ASIC while handling the rest on the GPU/CPU, creating a hybrid GPU + ASIC system for Bitcoin address generation.

However, there are 2 major obstacles 1st ASICs are built for a single, highly optimized task (Bitcoin SHA-256 hashing). They deliver extreme speed and efficiency, but they don’t support RIPEMD-160 hashing, meaning we would still need a GPU or CPU for that step. This makes the overall speed gain questionable.
2nd Even if the ASIC operates at full potential, the real question is whether we can transfer data fast enough between the ASIC and GPU/CPU to maintain efficiency.

Even if we successfully solve both hashing optimization and data transfer issues, there’s another problem: As you say :The EC throughput also scale up proportionally? You seem confident about this, but I have my doubts. If EC operations remain the bottleneck, then optimizing hashing alone wouldn’t provide the expected speed boost.What do you think? Would solving hashing and transfer limitations truly lead to a proportional increase in EC throughput?

[WanderingPhilospher]

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?

Where was the 4.8 MK/s at? I saw a bunch of 2 MK/s speeds. Maybe you did not show that part? And you only get that speed if you only search 1 address at a time?

Also, your bit mechanism seems broken. If you are searching in 69, but you have 68 ranges in your saved progress, that seems broken. Or am I missing something and that video has nothing to do with your comments/questions lol.

[citb0in]

I don't know if anyone has done this before, but I was with a man who has the gift of remote viewing. He says the key to Puzzle 68 lies between E0000000000000000 and E0FFFFFFFFFFFFFFF. 

Tell him, he is totally wrong 

[WanderingPhilospher]

I don't know if anyone has done this before, but I was with a man who has the gift of remote viewing. He says the key to Puzzle 68 lies between E0000000000000000 and E0FFFFFFFFFFFFFFF. 

I wouldn't call it a gift, it came standard with my PC, but I too have remote viewing with my Remote Desktop Protocol. However, it has never given me any hints to where the keys may lie, for any of the challenges. Maybe mine is faulty??!!