Bitcoin puzzle transaction ~32 BTC prize to who solves it

[mjojo]

Sorry I bring above topic here, maybe @WanderingPhilospher, @Brainless or anyone here can explain for this subtraction concept. Thank you

What's your question? Anything specific?

That was just an example of range reduction via subtraction & division. As you can see, you can search in a smaller bit range but you have more public keys to look for.

for about subtraction, example ==> pubkey target - pubkey = pubkey result, or in other words  X - 5 = Y and still have two variable in non decimal so how to define Y in decimal?

[Cricktor]

~~~

I don't know what's wrong in your head but with this new bs you finally got on my ignore list (I strongly suggest to others to do the same). This "the creator replaces found solutions" fud/crap/ill-fantasy is beyond boring and annoying. Ever wondered why this didn't happen with #120, #125 and #130 e.g.?

When you posted to sell your "magic bullet" to withdraw puzzle solutions safely different from recognized and valid ways, I already had mostly enough of your nonsense. Anyway, without a well populated ignore list this thread became almost unreadable. YMMV...

[pbies]

Why all these "Newbies" are posting here?

Is it one moron with schizophrenia or many personalities of one guy?

Can we remove their bs once and forever blocking accounts or what?

[hotmoney]

There's a lot of shit on this forum, no one knows anything.

Soon I will prove to you the tx efficient method

[Kelvin555]

There's a lot of shit on this forum, no one knows anything.

Soon I will prove to you the tx efficient method

You acting desperate is why no one will trust you, and especially with 6.7btc($700k).

make a tx with an absurdly low fee and publish the private key here after transmitting it, if nobody manages to replace it, you will have credibility.

Just like @mcdouglasx told you, do this and if no one here could intercept it, then we will all trust you

[tifosi87]

How about similarity can we generate smaller ecc  to find the right key

[fireman3100]

If someone has data on other 1BY8GQbnueYo prefixes with private keys I would like to get with you and work together on this project. You can email me directly at freshstart2900@outlook.com.

[bibilgin]

If someone has data on other 1BY8GQbnueYo prefixes with private keys I would like to get with you and work together on this project. You can email me directly at freshstart2900@outlook.com.

MrGPBit can help you. Maybe it's you?

My name is Lee and my email is freshstart2900@outlook.com.

You also said your name is Lee. Are you Macedonian?
Is this similarity just a coincidence?

[ABCbits]

maybe bitcoin could prevent this by updating code?
if seen in mempool, cant replace if receiver changes.
--snip--

That sounds like back when RBF didn't exist.

Why all these "Newbies" are posting here?

Is it one moron with schizophrenia or many personalities of one guy?

Can we remove their bs once and forever blocking accounts or what?

Not only here (this thread), but also other thread that talks about Bitcoin puzzle or cracking Bitcoin cryptography. Also see this discussion, "Puzzle hunters" being terrible at English.

[Zoning5264]

While we're waiting for RTX 5090 here's some really fast jumper for 64-bit CPUs.

This is 100% working code as I'm using it to test that my CUDA kernel jumps correctly. I really needed it to be as fast as possible so I don't get old waiting for results to validate.

This uses libsecp256k1 internal headers with inlined field and group basic operations, and does batched addition with non-dependent tree inversion loops (translation: a good compiler will use unrolling, SIMD and other CPU instructions to speed things up).

Group operations / second / thread is around 15 - 20 Mo/s on a high-end Intel CPU.

Compile with "-march=native" for best results.

No, this is not a fully-working puzzle breaker. You need to use your brain to add DP logic, saving, and collision checks. This is just the lowest-level detail: a very fast CPU kangaroo jumper for secp256k1.

This function also assumes that a jumped kangaroo can never be a point in the set of jump points, nor its opposite. This guarantee applies to my Kangaroo algorithm by design, so the logic of point doubling or point at infinity is not needed at all.

Code:

#include "field_impl.h"                 // field operations
#include "group_impl.h"                 // group operations

#define FE_INV(r, x)        secp256k1_fe_impl_inv_var(&(r), &(x))
#define FE_MUL(r, a, b)     secp256k1_fe_mul_inner((r).n, (a).n, (b).n)
#define FE_SQR(r, x)        secp256k1_fe_sqr_inner((r).n, (x).n)
#define FE_ADD(r, d)        secp256k1_fe_impl_add(&(r), &(d))
#define FE_NEG(r, a, m)     secp256k1_fe_impl_negate_unchecked(&(r), &(a), (m))

static
void jump_batch(
    secp256k1_ge * ge,
    const secp256k1_ge * jp,
    secp256k1_fe * xz,                  // product tree leafs + parent nodes
    secp256k1_fe * xzOut,
    U32 batch_size
) {
    secp256k1_fe t1, t2, t3;

    int64_t i;

    for (i = 0; i < batch_size; i++) {
        uint8_t jIdx;

#if JUMP_FUNC == JUMP_FUNC_LOW_52
        jIdx = ge[i].x.n[0] % NUM_JUMP_POINTS;
#elif JUMP_FUNC == JUMP_FUNC_LOW_64
        jIdx = (ge[i].x.n[0] | (ge[i].x.n[1] << 52)) % NUM_JUMP_POINTS;
#endif

        xz[i] = ge[i].x;
        FE_NEG(t1, jp[jIdx].x, 1);
        FE_ADD(xz[i], t1);                          // XZ[i] = x1 - x2
    }

    for (i = 0; i < batch_size - 1; i++) {
        FE_MUL(xz[batch_size + i], xz[i * 2], xz[i * 2 + 1]);
    }

    FE_INV(xzOut[batch_size * 2 - 2], xz[2 * batch_size - 2]);

    for (i = batch_size - 2; i >= 0; i--) {
        FE_MUL(xzOut[i * 2], xz[i * 2 + 1], xzOut[batch_size + i]);
        FE_MUL(xzOut[i * 2 + 1], xz[i * 2], xzOut[batch_size + i]);
    }

    secp256k1_ge * _a = ge;
    const secp256k1_fe * _inv = xzOut;

    for (i = 0; i < batch_size; i++) {
        uint8_t jIdx;

#if JUMP_FUNC == JUMP_FUNC_LOW_52
        jIdx = ge[i].x.n[0] % NUM_JUMP_POINTS;
#elif JUMP_FUNC == JUMP_FUNC_LOW_64
        jIdx = (ge[i].x.n[0] | (ge[i].x.n[1] << 52)) % NUM_JUMP_POINTS;
#endif

        const secp256k1_ge * _b = &jp[jIdx];

        FE_NEG(t1, _b->y, 1);                       // T1 = -y2
        FE_ADD(_a->y, t1);                          // Y1 = y1 - y2                     m = max_y + 2(1)
        FE_MUL(_a->y, _a->y, *_inv);                // Y1 = m = (y1 - y2) / (x1 - x2)   m = 1
        FE_SQR(t2, _a->y);                          // T2 = m**2                        m = 1
        FE_NEG(t3, _b->x, 1);                       // T3 = -x2
        FE_ADD(t2, t3);                             // T2 = m**2 - x2                   m = 1 + 2(1) = 3(2)
        FE_NEG(_a->x, _a->x, 1);                    // X1 = -x1                         m = max_x + 1
        FE_ADD(_a->x, t2);                          // X1 = x3 = m**2 - x1 - x2         max_x = 3 + max_x + 1
        secp256k1_fe_normalize_weak(&_a->x);

        FE_NEG(t2, _a->x, 1);                       // T2 = -x3                         m = 1 + 1 = 2
        FE_ADD(t2, _b->x);                          // T1 = x2 - x3                     m = 2 + 1 = 3
        FE_MUL(_a->y, _a->y, t2);                   // Y1 = m * (x2 - x3)               m = 1
        FE_ADD(_a->y, t1);                          // Y1 = y3 = m * (x2 - x3) - y2     m = 1 + 2 = 3
        secp256k1_fe_normalize_weak(&_a->y);

        ++_a;
        ++_inv;
    }
}

Easy to parallelize, let's add a wrapper that jumps a specific buffer of kangaroos:

Code:

static
void computeBatchJump(
    secp256k1_ge * ge,
    const secp256k1_ge * jp,
    U32 batch_size,
    U32 num_jumps
) {
    size_t tree_sz = (batch_size * 2 - 1) * sizeof(secp256k1_fe);

//    printf("Allocating %zu bytes for tree\n", tree_sz);

    secp256k1_fe * xz_1 = malloc(tree_sz);
    if (NULL == xz_1) return;

    secp256k1_fe * xz_2 = malloc(tree_sz);
    if (NULL == xz_2) return;

    for (uint32_t loop = 0; loop < num_jumps; loop++) {
        jump_batch(ge, jp, xz_1, xz_2, batch_size);
    }

    free(xz_1);
    free(xz_2);
}

And now, once you have a really big buffer of kangaroos, you can run the jumps on all of your physical cores:

Code:

#define JUMPS_PER_STAGE   32768

    secp256k1_ge * secp_ge = malloc(numElements * sizeof(secp256k1_ge));
    secp256k1_ge * secp_jp = malloc(NUM_JUMP_POINTS * sizeof(secp256k1_ge));

    // init the jump points, init the kangaroos to your needs
    // ...

    int numLaunches = 1;    // extra multiplier for the total number of jumps
    int numThr = omp_get_max_threads();

    // use the max amount of threads that exactly divides the number of items
    while (numThr > 0 && numElements % numThr) numThr--;

    U64 gePerPart = numElements / numThr;
    printf("\tThreads: %u; elements/thread: %lu\n", numThr, gePerPart);

    double ompStartTime = omp_get_wtime();

    for (U32 launchIdx = 0; launchIdx < numLaunches; launchIdx++) {
#pragma omp parallel for
        for (U32 tIdx = 0; tIdx < numThr; tIdx++) {
            U64 offset = tIdx * gePerPart;
            secp256k1_ge * localGE = secp_ge + offset;

            computeBatchJump(localGE, secp_jp, gePerPart, JUMPS_PER_STAGE);
        }
    }

    double ompEndTime = omp_get_wtime();
    elapsedTime = ompEndTime - ompStartTime;
    speed = (double) totalCount / elapsedTime;

Good luck.

Hello kTimesG,

I’m working on a Pollard’s Kangaroo implementation for secp256k1 and I’d love to achieve high performance for point arithmetic on CPU (in particular, large-scale multiplications of G and other points). Could you please share or publish your HPC‐optimized code and techniques? I’m especially interested in any optimized field/group operations, batched inversions, or other CPU‐level optimizations you’ve used to speed up these computations.

Thank you,  Zoning5264

[kTimesG]

While we're waiting for RTX 5090 here's some really fast jumper for 64-bit CPUs.

I’m working on a Pollard’s Kangaroo implementation for secp256k1 and I’d love to achieve high performance for point arithmetic on CPU (in particular, large-scale multiplications of G and other points). Could you please share or publish your HPC‐optimized code and techniques? I’m especially interested in any optimized field/group operations, batched inversions, or other CPU‐level optimizations you’ve used to speed up these computations.

Why would you need large-scale multiplications of G, it's only needed to create the initial kangaroos. Anyway, you can use libsecp256k1 for that or extract relevant code from it, like I did. You can also optimize further the code I posted, like keeping Y2 always in negated form and caching the jump index. More than that IDK if there's more to do on a CPU, as the batched inversion I presented is already the "parallel" tree-based version (hence the tradeoff with double-size tree storage, to avoid race conditions and r/w overlaps), not the "serial" version. Also, a RTX 4090 is 1000 times faster than a single-core high-end CPU, so my optimizations start there, not for CPU code.

[brainless]

While we're waiting for RTX 5090 here's some really fast jumper for 64-bit CPUs.

I’m working on a Pollard’s Kangaroo implementation for secp256k1 and I’d love to achieve high performance for point arithmetic on CPU (in particular, large-scale multiplications of G and other points). Could you please share or publish your HPC‐optimized code and techniques? I’m especially interested in any optimized field/group operations, batched inversions, or other CPU‐level optimizations you’ve used to speed up these computations.

Why would you need large-scale multiplications of G, it's only needed to create the initial kangaroos. Anyway, you can use libsecp256k1 for that or extract relevant code from it, like I did. You can also optimize further the code I posted, like keeping Y2 always in negated form and caching the jump index. More than that IDK if there's more to do on a CPU, as the batched inversion I presented is already the "parallel" tree-based version (hence the tradeoff with double-size tree storage, to avoid race conditions and r/w overlaps), not the "serial" version. Also, a RTX 4090 is 1000 times faster than a single-core high-end CPU, so my optimizations start there, not for CPU code.

First finding way was brute force by brain flayer
Where lot of option including stdin also available
Later just simple brute force were bitcrack, where upon multi request for stride option, and all other request for updation for some other function denied
3rd telariust  bring kangaroo CPU version by given idea to him by her 9 years old daughter, , and he created first gpu version too
Later Jean luc optimisation for better gpu base kangaroo
Long time No next level working seems, no new idea, new level programing, new logics etc
Hope 2025 will change
But again Question
After pubkey of 135... 160 pickup, what will be next
Broken wif ?
Or
......
Any comment's

[Kelvin555]

But again Question
After pubkey of 135... 160 pickup, what will be next
Broken wif ?
Or
......
Any comment's

It will still be the normal bruteforce of private key to hash160 or address.

Broken WIF is just adding more unnecessary difficulty to the challenge.

[brainless]

Raise your hands up those who find #67 privkey, but still waiting to hunt by bot script
In my view mostly leave to search by brute force and vanity, etc all installed bot script and wait for hunting, it's easy job

[l8orre]

Apologies if this has been addressed yet -
did anyone follow backwards to where these coins came from?

If this is mentioned earlier already, can someone maybe please just point me to there?
 

[b0dre]

Apologies if this has been addressed yet -
did anyone follow backwards to where these coins came from?

If this is mentioned earlier already, can someone maybe please just point me to there?
 

You can use "arkhamintelligence"

[mcdouglasx]

Apologies if this has been addressed yet -
did anyone follow backwards to where these coins came from?

If this is mentioned earlier already, can someone maybe please just point me to there?

I haven't read much about it here, but I think the creator Satoshi Rising knows how to cover his steps very well, otherwise, due to the popularity of the puzzle, we would already know who he is.

The transactions seem to originate from address 173ujrhEVGqaZvPHXLqwXiSmPVMo225cqT  which had a Total received amount of   56,457.80848111 BTC and a Final Balance of    312.04932734 BTC

Definitely a very big player of some kind.

Would be great if someone could find out who did this transaction.

We know that the funds came from this address:

https://blockchain.info/address/173ujrhEVGqaZvPHXLqwXiSmPVMo225cqT

It's quite a big player, with transactions every day.

Is this an exchange?

Like someone was saying here before, the guy that holds those 256 addresses has now some power over us, if suddenly we see that the addresses from 50 to 256 are spent, we will all feel a bit scared, no? 

We wouldn't know if they were actually cracked (and this would raise some questions) or if it was an intentional transaction from the holder...

What is certain is that none of us knows who is behind this.

[bibilgin]

What is certain is that none of us knows who is behind this.

I know who he is.

He is very experienced in mathematics.
He has achieved serious success in software.
He helped Bitcoin become widespread from its early days.
He is a serious philanthropist and someone who supports people.

The only problem is that he does not respond to anyone on the Internet. He has restricted messaging from many places. He is a name that no one would ever think of and was born in a country.

[kTimesG]

What is certain is that none of us knows who is behind this.

I know who he is.

Aren't your "couple of weeks" off, we were all eager and anxious to hear you spell out the "HEX code" of your MATHEMATICAL and PROBABILITY-based crackpot theories. You know, the ones that defy the modern understanding of statistics. The one that disproves that independent events of an random uniform distribution does NOT have memory. The holy theory that shows that it is totally weird to have a coin flip heads 66 times in a row. The proof that the Gambler's Fallacy is a hoax. Yes, I mean your continuous statements that you found statistical average distribution of prefixes in a double hashed cryptographically secure system, which were built on the very basis of acting exactly as a pure random numbers generator.

Disappointement.

Now, since you're the guy that thinks that if you play a slot machine many times in a row will increase your win chances, you should either keep quiet and accept your losses, or show that the last 500 years of MATHEMATICS and PROBABILITY got it wrong indeed, and proof to us that having two consecutive private keys produce the exact same hash is more unlikely than having them different any other way won't you say?

[hoanghuy2912]

Actually I still think this puzzle was created to sell the solution for business purposes and in fact no one has solved it, the people who have solved it are actually the same person or people from their organization