Author

Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 172. (Read 230896 times)

jr. member
Activity: 69
Merit: 2
Unfortunately, if the division results in a decimal number, the result will be incorrect.
newbie
Activity: 49
Merit: 0
a mathematical curiosity that maybe could help the puzzle:

all numbers even that respects this succession 4,10,16,22,28,34,40,46.....To infinity
divided by 3

plus the sum of +1 to the same number divided by 3, results in an integer, odd number.

Code:
target = 100
target_2 = 100+1 #= 101

t1= target//3  #= 33.333333333333336
t2= target_2//3  #= 33.666666666666664

r= t1+t2 # = 67
---snipp---

t1 = t2 = 33
r will not result in 67 as you said, r=66



33.333333333333336+33.666666666666664 = 67
use 1 "/" symbol, 2 " //" is for rounding, sorry.
even if you run the script it gives you like

pk decimal=67

03df9d70a6b9876ce544c98561f4be4f725442e6d2b737d9c91a8321724ce0963f

edit

and if you subtract 100-67= 33
you would get the division of 100/3 rounded to 33.



Unfortunately, this method does not work for all numbers:

target = 150
target_2 = 150+1 #= 151

t1= target/3 #= 50
t2= target_2/3 #= 50.333333333333336

r= t1+t2 # = 100.333333333333336
150 − 100.333333333333336 = 49.666666666666664
member
Activity: 239
Merit: 53
New ideas will be criticized and then admired.
a mathematical curiosity that maybe could help the puzzle:

all numbers even that respects this succession 4,10,16,22,28,34,40,46.....To infinity
divided by 3

plus the sum of +1 to the same number divided by 3, results in an integer, odd number.

Code:
target = 100
target_2 = 100+1 #= 101

t1= target//3  #= 33.333333333333336
t2= target_2//3  #= 33.666666666666664

r= t1+t2 # = 67
---snipp---

t1 = t2 = 33
r will not result in 67 as you said, r=66



33.333333333333336+33.666666666666664 = 67
use 1 "/" symbol, 2 " //" is for rounding, sorry.
even if you run the script it gives you like

pk decimal=67

03df9d70a6b9876ce544c98561f4be4f725442e6d2b737d9c91a8321724ce0963f

edit

and if you subtract 100-67= 33
you would get the division of 100/3 rounded to 33.
hero member
Activity: 630
Merit: 731
Bitcoin g33k
a mathematical curiosity that maybe could help the puzzle:

all numbers even that respects this succession 4,10,16,22,28,34,40,46.....To infinity
divided by 3

plus the sum of +1 to the same number divided by 3, results in an integer, odd number.

Code:
target = 100
target_2 = 100+1 #= 101

t1= target//3  #= 33.333333333333336
t2= target_2//3  #= 33.666666666666664

r= t1+t2 # = 67
---snipp---

t1 = t2 = 33
r will not result in 67 as you said, r=66
newbie
Activity: 49
Merit: 0
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. Roll Eyes
newbie
Activity: 72
Merit: 0
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
newbie
Activity: 8
Merit: 0
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?.
hero member
Activity: 862
Merit: 662
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.
jr. member
Activity: 69
Merit: 2
Is there a way to determine if a point on the curve is even or odd?
jr. member
Activity: 56
Merit: 1

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
jr. member
Activity: 56
Merit: 1
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.
copper member
Activity: 1330
Merit: 899
🖤😏

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.
jr. member
Activity: 50
Merit: 1
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
copper member
Activity: 1330
Merit: 899
🖤😏
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!
member
Activity: 239
Merit: 53
New ideas will be criticized and then admired.
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.
copper member
Activity: 1330
Merit: 899
🖤😏
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?
newbie
Activity: 8
Merit: 0
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.
jr. member
Activity: 69
Merit: 2
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.  Sad



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
member
Activity: 110
Merit: 61
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.
copper member
Activity: 1330
Merit: 899
🖤😏
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.😅
Jump to: