Bitcoin puzzle transaction ~32 BTC prize to who solves it

[mcdouglasx]

its not blind searching

No its not blind search it actually a dummy search

@kalos15btc There is no relationship if two publickey keys share a partial RMD hash even if you found an address with 159 bits exactly equals to another address, there is not going to be a relationshipt between the publickeys

I have this rmd160 as my address
000000009f012a539f3df386f0bddbb874af55ec

I should get to work and find  this address  1111111111111111111114oLvT2

With rmd160 of
0000000000000000000000000000000000000000 ? Lol I'm done.
 

This time I agree with you @digaran

you did not understand, im searching for substracted public keys, im searching for their range where exactly,, 110bits 112 118 109 102 bits,,  then like that public key 13 same hash160 digits, than means its in that range , so i scan the range if i found it there i can brake the 130,, thats how i think tell me if im wrong
exemple 10 substracted of 130
i found same 10 first lettre of uncompressed adress i have the pk, so i search in that range of pk the address similar in substracted if i found it i do + and find the target,,, am i wrong ??

ECC and rmd160 are different, you won't find any similarity there.

the matches you find are just that, random matches.

[1715345982]

1715345982

[1715345982]

1715345982

[1715345982]

1715345982

[1715345982]

1715345982

[1715345982]

1715345982

[digaran]

I'm bored, nothing interesting is happening around these woods no more.  Nobody has new and exciting ideas no more.

Something on mind for some time now, I wonder why 160 bit? Why not keep adding coins to 165, 170 etc?

And is it really feasible brute forcing any key beyond 80 bit? With no pub exposed of course.

I guess from 81 to 159 will not be solved in the next decade, why bother keeping them in there when we can use them as extra incentive for higher ranges, like adding them to 165, 170, 175 etc?

Good luck to all.😴

[james5000]

Can someone please explain how to divide a point on the curve by 2?

I have been working on software for searching by public key, and I can divide by 2 by performing scalar multiplication by the inverse scalar, but this operation takes a long time. If anyone knows a faster way to divide, I can improve my code and release the tool for others to test.

I'm bored, nothing interesting is happening around these woods no more.  Nobody has new and exciting ideas no more.

Something on mind for some time now, I wonder why 160 bit? Why not keep adding coins to 165, 170 etc?

And is it really feasible brute forcing any key beyond 80 bit? With no pub exposed of course.

I guess from 81 to 159 will not be solved in the next decade, why bother keeping them in there when we can use them as extra incentive for higher ranges, like adding them to 165, 170, 175 etc?

Good luck to all.

Have you noticed that there are at most 2^160 private keys instead of 2^256? Any key above that will generate a repeated RIPEMD160 hash.
That's why there are no keys from 161 to 256 anymore; the creator of the challenge realized it was redundant.

[lordfrs]

Can someone please explain how to divide a point on the curve by 2?

I have been working on software for searching by public key, and I can divide by 2 by performing scalar multiplication by the inverse scalar, but this operation takes a long time. If anyone knows a faster way to divide, I can improve my code and release the tool for others to test.

If you're going to divide a point by 2, you multiply it by the inverse of 2 by N.

[digaran]

Can someone please explain how to divide a point on the curve by 2?

I have been working on software for searching by public key, and I can divide by 2 by performing scalar multiplication by the inverse scalar, but this operation takes a long time. If anyone knows a faster way to divide, I can improve my code and release the tool for others to test.

There is no such a thing as division in EC math,  there is only add, subtract and multiply, whatever you do, at the end you'll have to use * by inverse.

I wish there was a puzzle 161, so kalos could tackle it by finding rmd160 collisions, he seems to be interested in that.😅

[_Counselor]

I have been working on software for searching by public key, and I can divide by 2 by performing scalar multiplication by the inverse scalar, but this operation takes a long time. If anyone knows a faster way to divide, I can improve my code and release the tool for others to test.

If you're using division by a fixed number, first you can cache inverse of this number to avoid inversion on each step, second you can decompose inverse into fixed double-add chain, then optimize it with special formulas for point tripling and readditions. But it is will be still expensive opertaion.

[james5000]

Can someone please explain how to divide a point on the curve by 2?

I have been working on software for searching by public key, and I can divide by 2 by performing scalar multiplication by the inverse scalar, but this operation takes a long time. If anyone knows a faster way to divide, I can improve my code and release the tool for others to test.

If you're going to divide a point by 2, you multiply it by the inverse of 2 by N.

I'm currently doing it exactly like this, but it's proving to be very expensive this way.  


My new software is for public keys, inspired by BSGS but a little different, using division and subtraction. Currently, I'm solving 35 bits in 3 seconds; this time is due to the delay in dividing a point. However, I believe that with the correct configuration, I will soon be able to break larger keys. I have some theories that have worked out very well in my tests, and I will be trying out more things to confirm.


For example, for a 35-bit key, I reduce the challenge #35 to 3 bits using my code. You input the public key and the 3-bit key '111,' and it returns 0x4aed21170, which is the equivalent private key of the public key.

Code:

key: 111
found: 00000000000000000000000000000000000000000000000000000004aed21170
Total time: 0 h, 0 m, 2 s

"111101" would be the key for #38.

Code:

key: 111101
found: 00000000000000000000000000000000000000000000000000000022382facd0
Total time: 0 h, 0 m, 13 s

[ing1996]

So any update on the progress of finding this key?
 First offset = 03982a5a42895a5cfe4b9b98e49f9389ebf9b3bf91c2289f1c5db3d944f46ec710
Half of above =
0291001b0dc6e5a2628cb4698eb00a6fb7dbd276dc2b214795f2fe52e61243aa9b
Half of 130?
0337374e00a32eaf009e9946035c0e69085627b60a844637d2b958dd83bcfa4383
The following is the subtracted key from #130
Second offset =
03d99bb89e8db75d20b882f13f8086fb39221858fa211de0346c926a93ae259b3a
Half of above?
03a3dc00bf5f7e7eec691569c7f67a15d3cdbb3a9994c9a5ec1430cffdb622cf9f

Now subtract half of first offset from half of #130 to get half of second offset.

Second offset is known, we need to work on first offset's half, use -1 divide by 2 script to reduce 18 bits from it, you'll have millions of new offsets and one of them is the target, now divide the #130 range by 2, subtract 18 bits from it and use the new range as your search range, input those millions offset keys and search the range.

Don't just try blind searching.😉

Hi! Can you show me how you do it?, to remove on video. I can't understand how you make the -1 divide by 2 scenario, and how you get the millionth offsets.

[digaran]

So any update on the progress of finding this key?
 First offset = 03982a5a42895a5cfe4b9b98e49f9389ebf9b3bf91c2289f1c5db3d944f46ec710
Half of above =
0291001b0dc6e5a2628cb4698eb00a6fb7dbd276dc2b214795f2fe52e61243aa9b
Half of 130?
0337374e00a32eaf009e9946035c0e69085627b60a844637d2b958dd83bcfa4383
The following is the subtracted key from #130
Second offset =
03d99bb89e8db75d20b882f13f8086fb39221858fa211de0346c926a93ae259b3a
Half of above?
03a3dc00bf5f7e7eec691569c7f67a15d3cdbb3a9994c9a5ec1430cffdb622cf9f

Now subtract half of first offset from half of #130 to get half of second offset.

Second offset is known, we need to work on first offset's half, use -1 divide by 2 script to reduce 18 bits from it, you'll have millions of new offsets and one of them is the target, now divide the #130 range by 2, subtract 18 bits from it and use the new range as your search range, input those millions offset keys and search the range.

Don't just try blind searching.

Hi! Can you show me how you do it?, to remove on video. I can't understand how you make the -1 divide by 2 scenario, and how you get the millionth offsets.

Hi there, I can't make a video but here is the script you can use to reduce bits.

Code:

from sympy import mod_inverse
import secp256k1 as ice
pub=ice.pub2upub('Here Compressed Public Key')
N=0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141

k=mod_inverse(2,N)
neg1=ice.point_negation(ice.scalar_multiplication(1))


def ters(Qx,Scalar):
     ScalarBin = str(bin(Scalar))[2:]
     le=len(ScalarBin)
     for i in range (1,le+1):
        if ScalarBin[le-i] == "0":
            Qx=ice.point_multiplication(k,Qx)
        else:
            Qx=ice.point_addition(Qx,neg1)
            Qx=ice.point_multiplication(k,Qx)
     return ice.point_to_cpub(Qx)


for x in range(1,65536):
         f= (ters(pub,x))
         data= open(“halfpub.txt”,”a”)
         data.write(f+”\n”)
         data.close()

Note this is where you decide how many bits should be reduced  
for x in range(1,65536):
For example reducing 26 bits requires 67108864 to be generated, 1 of them is the correct 26 bit reduced key.

My new software is for public keys, inspired by BSGS but a little different, using division and subtraction. Currently, I'm solving 35 bits in 3 seconds; this time is due to the delay in dividing a point. However, I believe that with the correct configuration, I will soon be able to break larger keys. I have some theories that have worked out very well in my tests, and I will be trying out more things to confirm.


For example, for a 35-bit key, I reduce the challenge #35 to 3 bits using my code. You input the public key and the 3-bit key '111,' and it returns 0x4aed21170, which is the equivalent private key of the public key.

Code:

key: 111
found: 00000000000000000000000000000000000000000000000000000004aed21170
Total time: 0 h, 0 m, 2 s

"111101" would be the key for #38.

Code:

key: 111101
found: 00000000000000000000000000000000000000000000000000000022382facd0
Total time: 0 h, 0 m, 13 s

Will you release for public to use?

[mcdouglasx]

I'm bored, nothing interesting is happening around these woods no more.  Nobody has new and exciting ideas no more.

Something on mind for some time now, I wonder why 160 bit? Why not keep adding coins to 165, 170 etc?

And is it really feasible brute forcing any key beyond 80 bit? With no pub exposed of course.

I guess from 81 to 159 will not be solved in the next decade, why bother keeping them in there when we can use them as extra incentive for higher ranges, like adding them to 165, 170, 175 etc?

Good luck to all.😴

It's not that we don't have new ideas, it's that we don't share them for our own interest, I thought about sharing how I reduce the bits from 130 to 107, in a range of 1000 possible pubkey, but I haven't done it, because the The time when you did something important and people contributed to the developer.
I don't have how to update my PC, so bit 100-107 is still too much for me. An example of what I am saying is keyhunt, it is a tool used by thousands or millions and has only received a little more than 10k in donations.
If I get to unlock a puzzle, I'll share it, while not because nowadays people don't even post the pk of the last puzzles solved.

[digaran]

I'm bored, nothing interesting is happening around these woods no more.  Nobody has new and exciting ideas no more.

Something on mind for some time now, I wonder why 160 bit? Why not keep adding coins to 165, 170 etc?

And is it really feasible brute forcing any key beyond 80 bit? With no pub exposed of course.

I guess from 81 to 159 will not be solved in the next decade, why bother keeping them in there when we can use them as extra incentive for higher ranges, like adding them to 165, 170, 175 etc?

Good luck to all.😴

It's not that we don't have new ideas, it's that we don't share them for our own interest, I thought about sharing how I reduce the bits from 130 to 107, in a range of 1000 possible pubkey, but I haven't done it, because the The time when you did something important and people contributed to the developer.
I don't have how to update my PC, so bit 100-107 is still too much for me. An example of what I am saying is keyhunt, it is a tool used by thousands or millions and has only received a little more than 10k in donations.
If I get to unlock a puzzle, I'll share it, while not because nowadays people don't even post the pk of the last puzzles solved.

If you can solve a puzzle with your idea, delete all social media accounts, remove yourself from online world, use a new pc with tor+vpn enabled to transfer the funds and never ever come back to this forum to post or share anything, and only solve the next puzzle after 4, 6 month.

If you like to live long. This is my advice to anyone.
However if you first share your idea and then puzzles start getting solved, nobody would look at your direction but if your idea could be used to crack any 256 bit key, then cryptocurrencies no more!

[kalos15btc]

I'm bored, nothing interesting is happening around these woods no more.  Nobody has new and exciting ideas no more.

Something on mind for some time now, I wonder why 160 bit? Why not keep adding coins to 165, 170 etc?

And is it really feasible brute forcing any key beyond 80 bit? With no pub exposed of course.

I guess from 81 to 159 will not be solved in the next decade, why bother keeping them in there when we can use them as extra incentive for higher ranges, like adding them to 165, 170, 175 etc?

Good luck to all.😴

i already find two puzzle with my methode of hash160 lowering the range of searching,and still im going to 130 135 my methode is working its just lowering and find the range in subed pub key to lower bit range 2 times yes when you find same 14 digits of hash160 than means that adress is in that range, but the search is not for one adress, i get a lot of addresses im trying , and no im not going to share the pk of any address i work hard for this, i advise you to try on 120 my methode, and get your bitcoin cash prize, ps: ill leave 50 satoshi on 130 for you, thank you

[digaran]

i already find two puzzle with my methode of hash160 lowering the range of searching,and still im going to 130 135 my methode is working its just lowering and find the range in subed pub key to lower bit range 2 times yes when you find same 14 digits of hash160 than means that adress is in that range, but the search is not for one adress, i get a lot of addresses im trying , and no im not going to share the pk of any address i work hard for this, i advise you to try on 120 my methode, and get your bitcoin cash prize, ps: ill leave 50 satoshi on 130 for you, thank you

So you already solved 120 and 125? Can we see their private keys? Since you have worked hard for them, and don't want to share them, you could sign a message with them without revealing them.

I advise you to grind all the puzzles with no mercy, don't even leave a single sat for anyone.
Kalos the merciless.😅

Ps, keep your pk ( whatever that means ) for your collection.


Can someone help to make this script working?

Code:

class EllipticCurve:
    def __init__(self, p, a, b, g_x, g_y, n):
        self.p = p
        self.a = a
        self.b = b
        self.g_x = g_x
        self.g_y = g_y
        self.n = n 

    def add_points(self, p1, p2):
        # Point addition logic here
        pass 

    def subtract_points(self, p1, p2):
        # Point subtraction logic here
        pass 

    def scalar_multiply(self, point, scalar):
        # Scalar multiplication logic here
        pass 

# Replace these values with your desired parameters
N = ...
P = ...
G = (..., ...)  # (x-coordinate, y-coordinate) 

# Create an instance of the EllipticCurve class with your parameters
curve = EllipticCurve(P, 0, 7, G[0], G[1], N) 

# Replace with your target public key and desired number of subtractions
target_public_key = "..."
num = 100 

# Example of point subtraction loop
subtract_point = G  # Initialize subtract_point with base point G 

for t in range(num + 1):
    # Perform point subtraction
    result = curve.subtract_points(subtract_point, G) 

    # Convert the result to hexadecimal representation
    h = (result[0], result[1]) 

    # Print or store the result as needed
    print("Subtraction result for iteration {}: {}".format(t, h)) 

    # Update subtract_point for the next iteration
    subtract_point = result 

# Note: You need to implement the add_points and subtract_points methods
# with the actual point addition and subtraction logic for your curve.

[lordfrs]

Code:

from sympy import mod_inverse
import secp256k1 as ice
pub=ice.pub2upub('Here Compressed Public Key')
N=0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141

k=mod_inverse(2,N)
neg1=ice.point_negation(ice.scalar_multiplication(1))


def ters(Qx,Scalar):
     ScalarBin = str(bin(Scalar))[2:]
     le=len(ScalarBin)
     for i in range (1,le+1):
        if ScalarBin[le-i] == "0":
            Qx=ice.point_multiplication(k,Qx)
        else:
            Qx=ice.point_addition(Qx,neg1)
            Qx=ice.point_multiplication(k,Qx)
     return ice.point_to_cpub(Qx)


for x in range(1,65536):
         f= (ters(pub,x))
         data= open(“halfpub.txt”,”a”)
         data.write(f+”\n”)
         data.close()

Note this is where you decide how many bits should be reduced  
for x in range(1,65536):
For example reducing 26 bits requires 67108864 to be generated, 1 of them is the correct 26 bit reduced key.

Will you release for public to use?

Yes this is my code, I can write bit reduction code in another way if you want. If you want, you can reduce bits by subtraction.


I'm developing a new algorithm for downgrading from a known bit range to the bit range I want. When I complete it by giving only 1 correct pubkey, I will share it here.

[lordfrs]

i already find two puzzle with my methode of hash160 lowering the range of searching,and still im going to 130 135 my methode is working its just lowering and find the range in subed pub key to lower bit range 2 times yes when you find same 14 digits of hash160 than means that adress is in that range, but the search is not for one adress, i get a lot of addresses im trying , and no im not going to share the pk of any address i work hard for this, i advise you to try on 120 my methode, and get your bitcoin cash prize, ps: ill leave 50 satoshi on 130 for you, thank you

So you already solved 120 and 125? Can we see their private keys? Since you have worked hard for them, and don't want to share them, you could sign a message with them without revealing them.

I advise you to grind all the puzzles with no mercy, don't even leave a single sat for anyone.
Kalos the merciless.😅

Ps, keep your pk ( whatever that means ) for your collection.


Can someone help to make this script working?

Code:

class EllipticCurve:
    def __init__(self, p, a, b, g_x, g_y, n):
        self.p = p
        self.a = a
        self.b = b
        self.g_x = g_x
        self.g_y = g_y
        self.n = n 

    def add_points(self, p1, p2):
        # Point addition logic here
        pass 

    def subtract_points(self, p1, p2):
        # Point subtraction logic here
        pass 

    def scalar_multiply(self, point, scalar):
        # Scalar multiplication logic here
        pass 

# Replace these values with your desired parameters
N = ...
P = ...
G = (..., ...)  # (x-coordinate, y-coordinate) 

# Create an instance of the EllipticCurve class with your parameters
curve = EllipticCurve(P, 0, 7, G[0], G[1], N) 

# Replace with your target public key and desired number of subtractions
target_public_key = "..."
num = 100 

# Example of point subtraction loop
subtract_point = G  # Initialize subtract_point with base point G 

for t in range(num + 1):
    # Perform point subtraction
    result = curve.subtract_points(subtract_point, G) 

    # Convert the result to hexadecimal representation
    h = (result[0], result[1]) 

    # Print or store the result as needed
    print("Subtraction result for iteration {}: {}".format(t, h)) 

    # Update subtract_point for the next iteration
    subtract_point = result 

# Note: You need to implement the add_points and subtract_points methods
# with the actual point addition and subtraction logic for your curve.

Code:

Pcurve = 2**256 - 2**32 - 2**9 - 2**8 - 2**7 - 2**6 - 2**4 -1 # The proven prime
N=0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 # Number of points in the field
Acurve = 0; Bcurve = 7 # This defines the curve. y^2 = x^3 + Acurve * x + Bcurve
Gx = 55066263022277343669578718895168534326250603453777594175500187360389116729240
Gy = 32670510020758816978083085130507043184471273380659243275938904335757337482424

def ECsub(point1x,point1y,point2x,point2y):
 
    neg_yq = Pcurve - point2y 
    
    return ECadd(point1x,point1y,point2x,neg_yq) # point1-point2

you can use ready ice library, it will be faster

Ice.pointnegatition finds the inverse of the point. It will be extracted with ice.pointadd

The simple logic of the subtraction is to subtract the cord y from the total point point

[james5000]

Is there a way to determine if a point on the curve is even or odd?

[albert0bsd]

Is there a way to determine if a point on the curve is even or odd?

if i have a satoshi each time that i see that question...

Sadly there is no way to determine if a point in the curve is odd or even, also there is no way to determine if bit in any position is 1 o 0 that would totally break ECDSA

I already try a lot of things to try to anwser that question, but none of them works and actually i really give up that way, my recomendation is not lose time in that topic (Unless you are full cryptographer with wide knowledge in that field)

Welcome to the club by the way.

[ing1996]

Is there a way to determine if a point on the curve is even or odd?

if i have a satoshi each time that i see that question...

Sadly there is no way to determine if a point in the curve is odd or even, also there is no way to determine if bit in any position is 1 o 0 that would totally break ECDSA

I already try a lot of things to try to anwser that question, but none of them works and actually i really give up that way, my recomendation is not lose time in that topic (Unless you are full cryptographer with wide knowledge in that field)

Welcome to the club by the way.

Hello 👋 all.
If we divide an odd number X by 2, as a result we will have a remainder of X.5, is it also impossible to determine whether there is a remainder at this point?.

[yoshimitsu777]

hello.For private key 2 the x and y values of pubkey are

c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5
1ae168fea63dc339a3c58419466ceaeef7f632653266d0e1236431a950cfe52a

i change generator points of elliptic curve to the values above.
let us assume we want to bruteforce scan the puzzles 1 to 20.
end range of puzzle20 is 0x100000 and normaly we would scan 1:100000 but as i changed G I divide the range by 2
therefore new reduced scan range is 0x1 to 0x80000

they keys found are:
4
26
70
101
A30
1498
649B

now we multiply by 2 and get correct prvkeys for seven puzzles 4 7 8 10 13 14 16

we miss thirteen keys and i understand that it didnt find them because they are and our scan used even.

someone please show what are the exact steps to find also rest keys within that range?

please show example with private key 4 for understanding

[Denis_Hitov]

hello.For private key 2 the x and y values of pubkey are

c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5
1ae168fea63dc339a3c58419466ceaeef7f632653266d0e1236431a950cfe52a

i change generator points of elliptic curve to the values above.
let us assume we want to bruteforce scan the puzzles 1 to 20.
end range of puzzle20 is 0x100000 and normaly we would scan 1:100000 but as i changed G I divide the range by 2
therefore new reduced scan range is 0x1 to 0x80000

they keys found are:
4
26
70
101
A30
1498
649B

now we multiply by 2 and get correct prvkeys for seven puzzles 4 7 8 10 13 14 16

we miss thirteen keys and i understand that it didnt find them because they are and our scan used even.

someone please show what are the exact steps to find also rest keys within that range?

please show example with private key 4 for understanding

Please post the code so it's more clear what you're talking about.