Bitcoin puzzle transaction ~32 BTC prize to who solves it

[mcdouglasx]

Main question is, how can we guess the first few digits? If even if we guess the 4 first digits correctly, the fifth digit would cause a problem if we make a mistake.

sincerely i have not investigated much in this technique, due to lack of time.
I only know that dividing by 5 with this technique, you will not worry about floating numbers.
I have applied the technique in 2 rounds and everything seems to be on the right track.
honestly do not know how many rounds are possible, but in my opinion it is a good idea.

Code:

x=2000000000000000
t=1185429467683753

A0=x-t
>>814570532316247

A1=t/5
>>237085893536750.6
A2=A0/5
>>162914106463249.4

A3=t-A1
>>948343574147002.4
A4= A0-A2
>>651656425852997.6


A5=A4-A1
>>785429467683753

A6=A3-A2
>>414570532316247

#---------------------------

t=A5
>>785429467683753
A0=A6
>>414570532316247

A1=t/5
>>157085893536750.6
A2=A0/5
>>82914106463249.4

A3=t-A1
>>628343574147002.4
A4= A0-A2
>>331656425852997.6


A5=A3-A2
>>545429467683753

A6=A4-A1
>>414570532316247

we obtain.
target=1185429467683753
  R=      545429467683753

[1715285772]

1715285772

[1715285772]

1715285772

[1715285772]

1715285772

[1715285772]

1715285772

[nomachine]

I'm not talking about missing characters or puzzle 66, I'm talking about a way to determine last characters of a private key by working with points.

Ok.

I'm working on Kangaroo Twimi algorithm on  hash160.
I don't know if it will work, but this is an idea.
It uses two EC_POINT objects (K and W) and iteratively moves them around the elliptic curve by adding random steps until they land on the same point.
When the Kangaroo and Wallaby points collide, the algorithm returns the discrete logarithm k.

Code:

bool kangarooTwimi(const EC_GROUP* group, const BIGNUM* order, BIGNUM* x, BIGNUM* result) {
    BIGNUM* k = BN_new();
    BIGNUM* k1 = BN_new();
    BIGNUM* k2 = BN_new();
    BIGNUM* x1 = BN_new();
    BIGNUM* x2 = BN_new();

    // Set k to a random value
    BN_rand_range(k, order);

    EC_POINT* G = EC_POINT_new(group);
    EC_POINT* kG = EC_POINT_new(group);
    EC_POINT* xG = EC_POINT_new(group); // Create an EC_POINT for x

    EC_POINT_mul(group, G, k, NULL, NULL, NULL); // G = k * G

    while (true) {
        EC_POINT_mul(group, kG, NULL, G, k, NULL); // kG = k * G

        // Use EC_POINT_mul to compute xG = x * G
        EC_POINT_mul(group, xG, NULL, NULL, x, NULL);

        // Extract affine coordinates
        EC_POINT_get_affine_coordinates_GFp(group, kG, k1, NULL, NULL);
        EC_POINT_get_affine_coordinates_GFp(group, xG, x1, NULL, NULL);

        if (BN_cmp(k1, x1) == 0) {
            BN_copy(result, k);
            BN_free(k);
            BN_free(k1);
            BN_free(k2);
            BN_free(x1);
            BN_free(x2);
            EC_POINT_free(G);
            EC_POINT_free(kG);
            EC_POINT_free(xG);
            return true;
        }

        BN_add(k, k, BN_value_one());
    }
}

rest is similiar as Bytea HASH160 Search from here :
https://bitcointalk.org/index.php?topic=1306983.msg63029958#msg63029958

100% OpenSSL code...

[digaran]

Main question is, how can we guess the first few digits? If even if we guess the 4 first digits correctly, the fifth digit would cause a problem if we make a mistake.

sincerely i have not investigated much in this technique, due to lack of time.
I only know that dividing by 5 with this technique, you will not worry about floating numbers.
I have applied the technique in 2 rounds and everything seems to be on the right track.
honestly do not know how many rounds are possible, but in my opinion it is a good idea.
........
we obtain.
target=1185429467683753
  R=      545429467683753

Will this work with your script of dividing by 3 you have posted before? Or do you have a script for this one as well?

Ok.
I'm working on Kangaroo Twimi algorithm on  hash160.
I don't know if it will work, but this is an idea.
It uses two EC_POINT objects (K and W) and iteratively moves them around the elliptic curve by adding random steps until they land on the same point.
When the Kangaroo and Wallaby points collide, the algorithm returns the discrete logarithm k.
.....
 rest is similiar as Bytea HASH160 Search from here :
https://bitcointalk.org/index.php?topic=1306983.msg63029958#msg63029958

100% OpenSSL code...

I wish I knew anything about coding, I could give my opinion, but your idea is great, I can work on different values until I get a result, but could you also work on a scalar mod n script alone please?  I mean just scalar mod n, no EC involved, scratch that, I believe if you can write a script where it takes both scalar and points and does the magic on both but with the ability to output points for scalar results.  If you don't understand me, I will explain later, I'm in pain now for walking a lot today.😉

Anyone knows anything with more fire power than sage cell or google colab etc? I'm running some scripts on them but they can't handle the load, I'm trying to find lambda and beta for different curve parameters, mapping points from secp256k1 to a 128 bit curve to see if it can be done.  
I was thinking, why there is no such infrastructure like sage cell, or Gcolab etc already available for blockchain/Bitcoin developers to use?
Should we all appeal to our beloved dragon to sponsor something like that?  I think if we all collectively ask nicely he will make it happen, right? 😉
[Digaran's note, consecutive posts merged due to another post being removed from between my posts.] 😉

[nomachine]

I wish I knew anything about coding

If you think realistically there are at least 10,000 programmers trying to solve the Puzzle 66 at the same time.
The result is visible on the blockchain:
https://www.blockchain.com/explorer/addresses/btc/13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so
They are helpless for now to solve any Puzzle from 66 and above  that does not have a Public Key displayed.
And if they have,  everything above 130 it is simply impossible to solve without huge investments that do not pay off.
So it doesn't really matter here if you know how to code or not. We are all equal in the face of an unsolvable problem.

Anyone knows anything with more fire power than sage cell or google colab etc? I'm running some scripts on them but they can't handle the load

Don't try to do that on shared services. Even if you have a large load on dedicated servers,  it can happen that you get banned from the same.

[AlanJohnson]

I wish I knew anything about coding

If you think realistically there are at least 10,000 programmers trying to solve the Puzzle 66 at the same time.
The result is visible on the blockchain:
https://www.blockchain.com/explorer/addresses/btc/13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so
They are helpless for now to solve any Puzzle from 66 and above  that does not have a Public Key displayed.
And if they have,  everything above 130 it is simply impossible to solve without huge investments that do not pay off.
So it doesn't really matter here if you know how to code or not. We are all equal in the face of an unsolvable problem.

Anyone knows anything with more fire power than sage cell or google colab etc? I'm running some scripts on them but they can't handle the load

Don't try to do that on shared services. Even if you have a large load on dedicated servers,  it can happen that you get banned from the same.

^^^^^ This is the best and logical answer on this forum ^^^^^^

Most people here just wasting their time trying to solve things that are unsolvable with current hardware (at least hardware available to them).

Even using blind random cracking - realistically it's not gonna be solved in any sane amount of time.

[digaran]

Most people here just wasting their time trying to solve things that are unsolvable with current hardware (at least hardware available to them).

Even using blind random cracking - realistically it's not gonna be solved in any sane amount of time.

Agreed, with current tools it's the same as before, extremely difficult to solve the DLP, but one has to penetrate deep into the unknown territories of math and elliptic curves, then you will realize everything is in the group order N, for each curve you'd need to find the weaknesses of N instead of G, or P.
Just to show one example, take this key  :

Code:

000000000000000000000000000000014551231950b75fc4402da1732fc9bebf

When you first look at it, what do you think would happen if you divide it by 2? Normally you'd say a key with 31 leading zeros. But in reality the result mod n is :

Code:

8000000000000000000000000000000000000000000000000000000000000000

Can you see the difference? There are also other hidden properties, keys etc.
One thing you should think about, is there a way to reduce a number to a perfect composite number and then easily dividing that composite number to reach a range close to 2^65? I believe with a certain subtraction tricks, we can do that, I have done it, but I know the key so it doesn't count, I want to know how to operate with 2 unknown points without knowing the distance between them, whether or not we can reach a composite point as a result of either subtraction and or division.  Like : 59, if we know the range, we could subtract it from 100 to have 41, now all we need is to subtract 9 from 41 to get to 32, and now we can safely divide 32 by 2 a few times to reach 8, where 8 is our desired small range where we can brute force under an hour. The question is, how can we determine that 9 is the right key to reach 32? By operating with scalar mod n of course, first we study and learn then we go for our targets in points.

[AlanJohnson]

Just to show one example, take this key  :

Code:

000000000000000000000000000000014551231950b75fc4402da1732fc9bebf

When you first look at it, what do you think would happen if you divide it by 2? Normally you'd say a key with 31 leading zeros. But in reality the result mod n is :

Code:

8000000000000000000000000000000000000000000000000000000000000000

Can you see the difference? There are also other hidden properties, keys etc.
One thing you should think about, is there a way to reduce a number to a perfect composite number and then easily dividing that composite number to reach a range close to 2^65? I believe with a certain subtraction tricks, we can do that, I have done it, but I know the key so it doesn't count, I want to know how to operate with 2 unknown points without knowing the distance between them, whether or not we can reach a composite point as a result of either subtraction and or division.  Like : 59, if we know the range, we could subtract it from 100 to have 41, now all we need is to subtract 9 from 41 to get to 32, and now we can safely divide 32 by 2 a few times to reach 8, where 8 is our desired small range where we can brute force under an hour. The question is, how can we determine that 9 is the right key to reach 32? By operating with scalar mod n of course, first we study and learn then we go for our targets in points.

I'm afraid this is the whole point where all that cryptography works. If you would be able to crack it in an easy way - it would be useless.

Maybe you are some kind of mathematical genius and you will discover something new ... But i guess there is a bunch of much smarter people than you trying to resolve such problems and since larger puzzles are still on their places they didn't invented anything new.

[nomachine]

It might be possible mathematically speaking :

https://arxiv.org/pdf/2302.06639.pdf

Technologically speaking....

We don't have the hardware (arithmetic circuits) available for "126 133 Cat Qubits"  

[AlanJohnson]

It might be possible mathematically speaking :

https://arxiv.org/pdf/2302.06639.pdf

Technologically speaking....

We don't have the hardware (arithmetic circuits) available for "126 133 Cat Qubits"  

Let's back to earth...

At some point I had an idea (probably very stupid cause i'm complete nood in maths)

In few program (like keyhunt, bitcrack) there is an option  called STRIDE.

As I understand that option simply defines a step (it skips given value) in searching for private key.

Normally scanning a large range (like puzzle 66) is impossible with home computer. But when we use quite high stride we can search the whole range in matter of seconds. (of course it will skip massive amount of keys)

And here is my thought: Let's say we have a 66 bit private key. Such key must be a multiple of smaller number. What if we use STRIDE option big enough to very fast scan the whole range and that stride value would be a number that multiplied is our private key ?

Now, some may say ... but how do you know which exactly STRIDE value use ?  And here my only answer is to write a program that would randomly generate STRIDE with given length (long enough to fast scan the whole range) and constantly seeking the range with new stride.

Can it work ? Or am i missing something here (i am sure i am missing something)

[nomachine]

Let's say we have a 66 bit private key. Such key must be a multiple of smaller number

Why numbers at all?

Let's say we have a Puzzle 65, 64, 63 private keys in bytes:

Code:

Puzzle 65 b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\xa88\xb15\x05\xb2hg'
Puzzle 64 b"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xf7\x05\x1f'\xb0\x91\x12\xd4"
Puzzle 63 b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00|\xce^\xfd\xac\xcfh\x08'

and so on....

Do you see how many leading zeros there are and how small the end is in bytes?

b'\x00' * 23 (twenty-three zeroes) + 9 bytes

You need to generate the last 9 bytes to get full WIF (from 66 to 71 bits).

 I went one step further now. To represent hash160 directly in the vector as bytes and

 

Code:

   std::vector<std::vector<unsigned char>> target_hash160_list = {
        {0x20, 0xd4, 0x5a, 0x6a, 0x76, 0x25, 0x35, 0x70, 0x0c, 0xe9, 0xe0, 0xb2, 0x16, 0xe3, 0x19, 0x94, 0x33, 0x5d, 0xb8, 0xa5},
        {0x73, 0x94, 0x37, 0xbb, 0x3d, 0xd6, 0xd1, 0x98, 0x3e, 0x66, 0x62, 0x9c, 0x5f, 0x08, 0xc7, 0x0e, 0x52, 0x76, 0x93, 0x71},
        {0xe0, 0xb8, 0xa2, 0xba, 0xee, 0x1b, 0x77, 0xfc, 0x70, 0x34, 0x55, 0xf3, 0x9d, 0x51, 0x47, 0x74, 0x51, 0xfc, 0x8c, 0xfc},
        {0x61, 0xeb, 0x8a, 0x50, 0xc8, 0x6b, 0x05, 0x84, 0xbb, 0x72, 0x7d, 0xd6, 0x5b, 0xed, 0x8d, 0x24, 0x00, 0xd6, 0xd5, 0xaa},
        {0xf6, 0xf5, 0x43, 0x1d, 0x25, 0xbb, 0xf7, 0xb1, 0x2e, 0x8a, 0xdd, 0x9a, 0xf5, 0xe3, 0x47, 0x5c, 0x44, 0xa0, 0xa5, 0xb8},
        {0xbf, 0x74, 0x13, 0xe8, 0xdf, 0x4e, 0x7a, 0x34, 0xce, 0x9d, 0xc1, 0x3e, 0x2f, 0x26, 0x48, 0x78, 0x3e, 0xc5, 0x4a, 0xdb},
        {0xfe, 0x7c, 0x45, 0x12, 0x67, 0x31, 0xf7, 0x38, 0x46, 0x40, 0xb0, 0xb0, 0x04, 0x5f, 0xd4, 0x0b, 0xac, 0x72, 0xe2, 0xa2}
    };

 compare them directly afterwards without any conversion to hex.

This works fast as hell.  It is SO fast that you can barely see the numbers on the display. Flashing characters on the screen....
But it's not fast enough for Puzzles over 60...Need GPU....

[AlanJohnson]

Let's say we have a 66 bit private key. Such key must be a multiple of smaller number

Why numbers at all?

Let's say we have a Puzzle 65, 64, 63 private keys in bytes:

Code:

Puzzle 65 b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\xa88\xb15\x05\xb2hg'
Puzzle 64 b"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xf7\x05\x1f'\xb0\x91\x12\xd4"
Puzzle 63 b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00|\xce^\xfd\xac\xcfh\x08'

and so on....

Do you see how many leading zeros there are and how small the end is in bytes?

b'\x00' * 23 (twenty-three zeroes) + 9 bytes

You need to generate the last 9 bytes to get full WIF (from 66 to 71 bits).

 I went one step further now. To represent hash160 directly in the vector as bytes and

 

Code:

   std::vector<std::vector<unsigned char>> target_hash160_list = {
        {0x20, 0xd4, 0x5a, 0x6a, 0x76, 0x25, 0x35, 0x70, 0x0c, 0xe9, 0xe0, 0xb2, 0x16, 0xe3, 0x19, 0x94, 0x33, 0x5d, 0xb8, 0xa5},
        {0x73, 0x94, 0x37, 0xbb, 0x3d, 0xd6, 0xd1, 0x98, 0x3e, 0x66, 0x62, 0x9c, 0x5f, 0x08, 0xc7, 0x0e, 0x52, 0x76, 0x93, 0x71},
        {0xe0, 0xb8, 0xa2, 0xba, 0xee, 0x1b, 0x77, 0xfc, 0x70, 0x34, 0x55, 0xf3, 0x9d, 0x51, 0x47, 0x74, 0x51, 0xfc, 0x8c, 0xfc},
        {0x61, 0xeb, 0x8a, 0x50, 0xc8, 0x6b, 0x05, 0x84, 0xbb, 0x72, 0x7d, 0xd6, 0x5b, 0xed, 0x8d, 0x24, 0x00, 0xd6, 0xd5, 0xaa},
        {0xf6, 0xf5, 0x43, 0x1d, 0x25, 0xbb, 0xf7, 0xb1, 0x2e, 0x8a, 0xdd, 0x9a, 0xf5, 0xe3, 0x47, 0x5c, 0x44, 0xa0, 0xa5, 0xb8},
        {0xbf, 0x74, 0x13, 0xe8, 0xdf, 0x4e, 0x7a, 0x34, 0xce, 0x9d, 0xc1, 0x3e, 0x2f, 0x26, 0x48, 0x78, 0x3e, 0xc5, 0x4a, 0xdb},
        {0xfe, 0x7c, 0x45, 0x12, 0x67, 0x31, 0xf7, 0x38, 0x46, 0x40, 0xb0, 0xb0, 0x04, 0x5f, 0xd4, 0x0b, 0xac, 0x72, 0xe2, 0xa2}
    };

 compare them directly afterwards without any conversion to hex.

This works fast as hell.  It is SO fast that you can barely see the numbers on the display. Flashing characters on the screen....
But it's not fast enough for Puzzles over 60...Need GPU....

I just tried your previous program (for puzzle 15) that is using openssl...

It works ok  but only for puzzle 15...

I edited the code with differend rmd160 hashes  and changed the  value int puzzle = 15  to a different puzzle but then it counts endlessly and never finds a solution.

If i want to try this program for different puzzles what parameters i need to change in the code

[nomachine]

If i want to try this program for different puzzles what parameters i need to change in the code

That's the first test script...You have a pm. Let's not bother others with technicalities here. 

[WanderingPhilospher]

Let's say we have a 66 bit private key. Such key must be a multiple of smaller number

This works fast as hell.  It is SO fast that you can barely see the numbers on the display. Flashing characters on the screen....
But it's not fast enough for Puzzles over 60...Need GPU....

Soooo nomachine, how fast is fast?
How fast can your script on your PC solve a 60 bit key?
You say it’s fast, just not fast enough to solve puzzles over 60, so how fast is fast?

[albert0bsd]

It is SO fast that you can barely see the numbers on the display.

Print ALL the keys on screen is stupid and slow

[digaran]

Let's say we have a 66 bit private key. Such key must be a multiple of smaller number

This works fast as hell.  It is SO fast that you can barely see the numbers on the display. Flashing characters on the screen....
But it's not fast enough for Puzzles over 60...Need GPU....

Soooo nomachine, how fast is fast?
How fast can your script on your PC solve a 60 bit key?
You say it’s fast, just not fast enough to solve puzzles over 60, so how fast is fast?

Hey hey now, it's not cool talking to a colleague like that, soooo is obvious you are making fun of his speed, lets say the script is so fast that it flashes on the screen very fast, and lets leave it at that.
Instead of smearing each other, lets develop an algorithm to show the world *who we are.
Proposal untested :
Subtract 2 from target, set as target2, set original key as target1, subtract n/2 from target1 and perform point torsion on it, subtract 1 from target2 then perform point torsion on it, now either sub or add the results together, check to see if you get any results.
Yesterday I managed to definitively find the value of last char of unknown keys, but I forgot it after going to get some coffee. 😐
I can't manage testing anything right now cause I resent myself for that.

Proposal 2 : normal division not using torsion, halve the target first, set as target2, original point as target1, divide both by starting range = n/2-100, end range = n/2+100, then add/sub results, check for a solution.

P2-2 : we need to find a way to get a composite number, even if it's as large as 255bit, remember do everything over scalar first, if our key is :

Code:

T2 :
000000000000000000000000000000014551231950b75fc4402da1732fc9bebf

Key inverse, -n :

Code:

fffffffffffffffffffffffffffffffd755db9cd5e9140777fa4bd19a06c8282
Now cut off this part from it :
fffffffffffffffffffffffffffffff000000000000000000000000000000000
By subtracting from target -n to have : T1
0000000000000000000000000000000d755db9cd5e9140777fa4bd19a06c8282

Set T1 and T2, do the division sub/add, with n/2-100 etc, check the result.
I know you will see the distance between them being divided, but try to divide one of the results which has many trailing zeros, divide by power of 2, until you reach to fractions, you will see that there is a possibility to do the same with unknown keys. Try these, I know you can find something, after all you taught me how to do point operations on EC. 😉

You know where to find my test scripts on project development. (Ground breaking etc).lol
*= who are we really? We will deal with this identity crisis later.😂

[nomachine]

so how fast is fast?

For first test is fast 

Print ALL the keys on screen is stupid and slow

I agree. but I need to have insight into what the application does exactly in the test phases.

soooo is obvious you are making fun of his speed, lets say the script is so fast that it flashes on the screen very fast

Even I joke about my speed.

[WanderingPhilospher]

so how fast is fast?

For first test is fast 

Print ALL the keys on screen is stupid and slow

I agree. but I need to have insight into what the application does exactly in the test phases.

soooo is obvious you are making fun of his speed, lets say the script is so fast that it flashes on the screen very fast

Even I joke about my speed.

No, it's a serious question. Maybe you are on to something, maybe not.

I wonder how fast it really is? What about 56 bit key or a 52 bit key? Do you not have any benchmarks?

[WanderingPhilospher]

Proposal untested :
Subtract 2 from target, set as target2, set original key as target1, subtract n/2 from target1 and perform point torsion on it, subtract 1 from target2 then perform point torsion on it, now either sub or add the results together, check to see if you get any results.
Yesterday I managed to definitively find the value of last char of unknown keys, but I forgot it after going to get some coffee. 😐
I can't manage testing anything right now cause I resent myself for that.

Proposal 2 : normal division not using torsion, halve the target first, set as target2, original point as target1, divide both by starting range = n/2-100, end range = n/2+100, then add/sub results, check for a solution.

P2-2 : we need to find a way to get a composite number, even if it's as large as 255bit, remember do everything over scalar first, if our key is :

I honestly get lost trying to figure out what you are trying to do.

If you had worked with smaller keys, whether hex or numbers, and shown an example of what you did on a smaller scale, it would be easier to follow.

And no, not just an example of the operations, but an example of the operations performed and the results at each operation, until you reached the outcome you were trying for.

[patsat]

Ok.

I'm working on Kangaroo Twimi algorithm on  hash160.
I don't know if it will work, but this is an idea.
It uses two EC_POINT objects (K and W) and iteratively moves them around the elliptic curve by adding random steps until they land on the same point.
When the Kangaroo and Wallaby points collide, the algorithm returns the discrete logarithm k.

Can you find one bit of the K nonce ?

[WanderingPhilospher]

^^^^^ This is the best and logical answer on this forum ^^^^^^

Most people here just wasting their time trying to solve things that are unsolvable with current hardware (at least hardware available to them).

Even using blind random cracking - realistically it's not gonna be solved in any sane amount of time.

I can agree, to an extent,This really depends on your hardware and strategy. And a lack of dedicated pool for Kangaroo/awareness is another big reason 130 seems impossible at the moment.

I can run a simple keyhunt/bitcrack/vansearch program and cut the 66 bit puzzle down to having a 1 in 2^30 chance, every few minutes with nothing but simple CPUs (think i5/i7 6th. 7th. 8th generation type).
With the higher puzzles currently at 130, group ops, is almost the same as brute forcing 66, 67, 68, 69 puzzles.

I bounce around all over the place with different strategies. but for now, I am sticking with my 2^30 chances for 66 bit puzzle.