Bitcoin puzzle transaction ~32 BTC prize to who solves it

[kTimesG]

Can't you read well? How old are you? lol

Do you know anything about Bram's software?
Bram, did you give any information about the software somewhere? That it's this fast, that it's this good? Has anyone seen it?

I am free to comment on any topic I want here.
Are you a judge? Prosecutor? Or a lawyer?

Are you a fart bug? lol

Man, I gave you several chances. Ignored.unignored/ignored/unignored. Now the final ignore.

Listen, you are acting like a 10-year old.

No, you are not free to comment on any topic you want here. There's also the forum rules.

You don't know how to debate properly. There is a difference between being arrogant and being totally rude.

You upfront call people idiots, which is enough reason to get you banned, which is where you will end up.

You're the kid that, when the math teacher enters the class, says "let me show how it's done..." lol.

You were catched lying several times. Plain out lies.

You have no idea how to hash a public key, but say you studied hashes for years. How do those two statements go together?

You claim faster software does not exist, when we have at least 3 people here having such software.

You claim people are not who they say they are, even after they prove that to you.

You can't understand the difference between "knowledge" and "useless data". No one cares about anything you say, or about any output of useless electricity-consuming methods you're up to.

Maybe you will go away willingly, if not, we all know how this will end.

[nomachine]

The problem here is that this puzzle was developed in collaboration with a mathematician. The number of models for piece sides was calculated in advance to be at a minimum, but still for only ONE SOLUTION to exist.

Then came genetic algorithms, since it was my PhD thesis topic at the time.
After a few months, full of experiments and Terminal colored grid display of solutions advancing in real-time, I decided to shift+delete the entire project.

This was the only time in mi life where I intendedly deleted a project I worked on, so to never touch it again or try to reconstruct it. I had in there even PNG files with the pieces, to display the solutions as if I owned the physical puzzle. It was becoming an addiction.

These guys are your competition, not me.

Solving problems requires down to Earth solutions.
Down to Earth solutions require computations.
Computations require electricity, not zero-point free energy.
Electricity costs money.

I'm seeking knowledge.

No, you are not free to comment on any topic you want here. There's also the forum rules.

I've been watching you write for a long time. You're the author of this whole puzzle, aren't you? You're observing everything we do from all sides—disinterestedly interested. Of course, you'll say that you're not. No problem. Everything is clear 

[Akito S. M. Hosana]

He is a Digaran—a mathematician, robot, AI, deity, and creator...  

[nomachine]

a mathematician, robot, AI, deity, and creator...  

I am going fishing 🎣

[bibilgin]

Can't you read well? How old are you? lol

Do you know anything about Bram's software?
Bram, did you give any information about the software somewhere? That it's this fast, that it's this good? Has anyone seen it?

I am free to comment on any topic I want here.
Are you a judge? Prosecutor? Or a lawyer?

Are you a fart bug? lol

Man, I gave you several chances. Ignored.unignored/ignored/unignored. Now the final ignore.

Listen, you are acting like a 10-year old.

No, you are not free to comment on any topic you want here. There's also the forum rules.

You don't know how to debate properly. There is a difference between being arrogant and being totally rude.

You upfront call people idiots, which is enough reason to get you banned, which is where you will end up.

You're the kid that, when the math teacher enters the class, says "let me show how it's done..." lol.

You were catched lying several times. Plain out lies.

You have no idea how to hash a public key, but say you studied hashes for years. How do those two statements go together?

You claim faster software does not exist, when we have at least 3 people here having such software.

You claim people are not who they say they are, even after they prove that to you.

You can't understand the difference between "knowledge" and "useless data". No one cares about anything you say, or about any output of useless electricity-consuming methods you're up to.

Maybe you will go away willingly, if not, we all know how this will end.

Let me tell you about a fact that has been established.

People go back to their childhood state as they get older.
I guess you could be one of these examples.

You apologized. You are still trying to look cool.
The traveler misread and used a word that tried to make me look small. I responded.

Since no one has responded to people like you until now, it is quite normal for you to consider yourself cool.

The fact that you prefer to portray people as Stupid, Idiot, and ignorant proves that you have psychological problems.

I did not break the forum rules.
Someone insulted me. "I responded."
Someone tried to humiliate me. "I made you apologize."
Someone tried to portray the English I misunderstood as ignorant. "I responded to that too."

In short, I defended myself. I did not mistreat anyone who did not insult or mistreat me.

You did not believe that I found the prefix 1MVDYgVaSN6.
"Did I prove it?" I did. Why?

I think that Bram is not KOWALA,(He answered politely. I did not say any bad words to him.)
RetriderCoder did it only with the power of his money. Has it been proven? No.

Nobody should think that they are very smart. The reason you think that you are smart is because nobody has answered you until now.

[Menowa*]

Stop acting like child guys, be mature instead of wasting countless pages here with no contribution to the puzzle.

[WanderingPhilospher]

1MVDYgVaSN6Qy3d7W5nqGAUziqwJpKyhGu

e2bff95aa8cdb927745977699198ec9bacad30c79f69cff90bca05aaccfd3f91

[zahid888]

1MVDYgVaSN6Qy3d7W5nqGAUziqwJpKyhGu

e2bff95aa8cdb927745977699198ec9bacad30c79f69cff90bca05aaccfd3f91

Let me take a shot at cracking it! What do you think—will it be an easy challenge ?

[kTimesG]

1MVDYgVaSN6Qy3d7W5nqGAUziqwJpKyhGu

e2bff95aa8cdb927745977699198ec9bacad30c79f69cff90bca05aaccfd3f91

This trick might be very useful for improving a vanity search with a long prefix, without looking for a full match. You skipped a lot of ranges to land on this hash, right?

[bibilgin]

As I wrote before,

I will give a reward when I win the reward for exchanging the prefixes 1MVDYgVaSN and 1MVDYgVaSN6 or for information.

I wish everyone good luck and a good life.

[mcdouglasx]

This forum thread has turned into a battlefield; it seems people here take everything to heart. I am thankful that I can write a couple of messages and then go to sleep peacefully. This is just a hobby, don't forget that it's important to remember that we are all in the same boat and that superficial differences do not determine our value. No one is better than anyone else; some may have more money than others, but that won't save us when death comes for us. No one deserves exclusive treatment unless you create a milestone and find a solution that doesn't rely on a farm of GPUs to win, I see you as equals. It is more meritorious to explore ideas than to use your knowledge to criticize them because it is a waste of talent, and criticizing is the easiest and least meritorious thing in the world. Can any idea be perfect? There are people who are happy, barefoot, and in the rain, and here we are fighting over the internet. Peace and love, and as Carl Sagan said, we are just a mote of dust in the vastness of the universe.

[nomachine]

This trick might be very useful for improving a vanity search with a long prefix, without looking for a full match. You skipped a lot of ranges to land on this hash, right?

You can implement hash comparison logic using unordered_map for fast lookups. Instead of comparing the entire 20-byte HASH160, you can compare only the first 8 bytes with unordered_map. The same approach can be applied to public keys or other data.

Cyclone

Code:

    // 8 keys are ready - time to use AVX2
    if (localBatchCount == HASH_BATCH_SIZE) {
        computeHash160BatchBinSingle(localBatchCount, localPubKeys, localHashResults);

        // Results check using unordered_map for the first 8 bytes
        for (int j = 0; j < HASH_BATCH_SIZE; j++) {
            char hash_buffer[9];
            hash_buffer[8] = '\0';
            std::memcpy(hash_buffer, localHashResults[j], 8);

            if (hash_table.find(hash_buffer) != hash_table.end()) {
                // First 8 bytes match, now check the full 20 bytes
                if (!matchFound && std::memcmp(localHashResults[j], targetHash160.data(), 20) == 0) {
                    #pragma omp critical
                    {
                        if (!matchFound) {

or

Code:

    std::unordered_map<std::string, int> baby_table;
    char key_buffer[9];
    int index;
    while (fread(key_buffer, 8, 1, pipe) == 1) {
        key_buffer[8] = '\0';
        fread(&index, sizeof(index), 1, pipe);
        baby_table[key_buffer] = index;
    }

Here is a link for reference:
https://bitcointalk.org/index.php?topic=5509916.msg65097786#msg65097786

This approach is incredibly fast but consumes a large amount of RAM, especially when the number of unique 8-byte prefixes is high. Every optimization has trade-offs—while something is gained, something else is lost.

The bigger challenge lies in optimizing SECP256K1 itself.

[kTimesG]

This trick might be very useful for improving a vanity search with a long prefix, without looking for a full match. You skipped a lot of ranges to land on this hash, right?

You can implement hash comparison logic using unordered_map for fast lookups. Instead of comparing the entire 20-byte HASH160, you can compare only the first 8 bytes with unordered_map.

I meant something else: let's say we want a match on the first 58 bits of the hash.

This means checking 2**58 hashes, on average.

But instead of scanning linearly one key after the next, jump around according to mcdouglasx/bibilgin strategies (trade off precision with probabilities).

That's why I said it can be a good improvement to find vanity addresses faster, but since there are skipped ranges, other matching prefixes might get lost, there is no violation. But this is not something that a vanity search would ever care about. Only something that should worry someone who wants to solve a puzzle in an efficient matter (e.g. an exact match).

[bibilgin]

As I wrote before,

I will give a reward when I win the reward for exchanging the prefixes 1MVDYgVaSN and 1MVDYgVaSN6 or for information.

I wish everyone good luck and a good life.

I couldn't send you a private message. Send me a telegram or mail please, I'll give you the SN.

On your own profile, in the personal message options, check Allow beginners to send you private messages (PM).

Then try PM again or let me know and I will PM you.

[nomachine]

But instead of scanning linearly one key after the next, jump around according to mcdouglasx/bibilgin strategies (trade off precision with probabilities).

No one can easily 'jump around' elliptic curve (EC) coordinates because they carry critical information about the point's location.

I recall that McDouglasX used a 'jumping' method by hardcoding the prefix to 03 (or 0x03 in hexadecimal) in python. This approach eliminates the need to check whether the y-coordinate is even or odd, as it always uses 03 as the prefix.

For example:

Code:

static inline std::string pointToCompressedHex(const Point &point) {
    return "03" + intXToHex64(point.x); // Always use "03" as the prefix
}

static inline void pointToCompressedBin(const Point &point, uint8_t outCompressed[33]) {
    outCompressed[0] = 0x03; // Always use 0x03 as the prefix
    Int temp;
    temp.Set((Int*)&point.x);
    for (int i = 0; i < 32; i++) {
        outCompressed[1 + i] = (uint8_t)temp.GetByte(31 - i);
    }
}

This method removes the need for the isEven check, but the performance gain is minimal because the check is already very fast. The original code uses a conditional statement (isEven(point.y) ? "02" : "03") to determine the prefix.

This approach has a trade-off: you may need to generate twice as many keys to achieve the same number of valid keys as the original code, since the hardcoded prefix does not account for the y-coordinate's parity.

[Akito S. M. Hosana]

And can we make it like a lottery game, randomly drawing numbers from two drums? My head is pounding from all this information. 

[kTimesG]

No one can easily 'jump around' elliptic curve (EC) coordinates because they carry critical information about the point's location.

You went too hardcore. This is what I'm assuming:

- generate EC starting pubkeys according to how many threads will run and the size of the range to scan
- copy them to GPU memory
- scan the range (one or more kernel calls), mark matching prefixes above XX bits (XX depends on range size)
- extract results after each run; maybe break earlier from finishing scanning the range if we are lucky (don't make all the kernel calls to finish the range)

Now, depending on the results, instead of continuing scanning the NEXT range, advance more or less, by skipping some number of ranges.

Generating the starting keys for some range is like 0.001% of the entire running time, it's not an issue. Also, it can be optimized with some constant jump offsets, if we always start with an aligned subrange (for example, aligned to 40 bits).

Just my 2 cents. Maybe WP scanned a lot and got lucky, he knows better why he did that.

[0x00usa]

As I wrote before,

I will give a reward when I win the reward for exchanging the prefixes 1MVDYgVaSN and 1MVDYgVaSN6 or for information.

I wish everyone good luck and a good life.

I couldn't send you a private message. Send me a telegram or mail please, I'll give you the SN.

On your own profile, in the personal message options, check Allow beginners to send you private messages (PM).

Then try PM again or let me know and I will PM you.

Thanks Mr. Bibilgin

[bibilgin]

Thanks Mr. Bibilgin

You're welcome, good luck.

[nomachine]

No one can easily 'jump around' elliptic curve (EC) coordinates because they carry critical information about the point's location.

You went too hardcore. This is what I'm assuming:

- generate EC starting pubkeys according to how many threads will run and the size of the range to scan
- copy them to GPU memory
- scan the range (one or more kernel calls), mark matching prefixes above XX bits (XX depends on range size)
- extract results after each run; maybe break earlier from finishing scanning the range if we are lucky (don't make all the kernel calls to finish the range)

Do you mean something like this? Let me express myself through pseudocode:

Code:

// Precompute starting keys
std::vector<Point> startingKeys = generateStartingKeys(totalRange, subrangeSize);

// Transfer to GPU
gpuMemory.copyToDevice(startingKeys);

// Launch GPU kernels
for (int i = 0; i < numSubranges; i += skipOffset) {
    gpuKernel<<<numBlocks, threadsPerBlock>>>(startingKeys[i], subrangeSize, criteria);
    gpuMemory.copyToHost(results);

    if (results.hasMatch()) {
        processResults(results);
        break; // Early termination
    }

    skipOffset = calculateSkipOffset(results); // Adjust skip offset dynamically
}

It requires extensive GPU programming, including:

Kernels, Threads, Blocks, and Grids: Understanding the hierarchical organization of threads in CUDA (or similar frameworks).
Memory Management: Efficiently transferring data between the CPU (host) and GPU (device).

You need ~ 20 weeks (for a highly optimized, scalable implementation).

And the outcome of this entire process remains uncertain.