Author

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

newbie
Activity: 17
Merit: 0
Where can I find CPUs for rent? Not GPUs, only CPUs?

Lamdalabs dot com
jr. member
Activity: 69
Merit: 2
Where can I find CPUs for rent? Not GPUs, only CPUs?
newbie
Activity: 17
Merit: 0
I have a script that’s searching for the private key of puzzles 66,67, and 68. Just by just by searching through the hex range 20000000000000000 - 2ffffffffffffffff
Same can be done with the rest of the addresses. I only have to search through 1 range, but I can search for 4 addresses all at once.
So puzzle 68 may be cracked before 66 🤷‍♂️
If anyone is interested let me know. I will definitely need more computer power. But it’s worth it.. I’ve already tested it with previous addresses. Works like a charm. https://ibb.co/jzZTHhV

One of the best ways to do it 👌🏻
jr. member
Activity: 50
Merit: 1


Here is another idea, lets see if it can be done or has any merits to it.

If we know the exact start and end range of a public key, we could divide the end range by a number to reduce it down as much as possible, maybe making it a 6 digits number, now we only have to change our 6 digit number and multiply it by the number which we first divided our end range with, we need to change the numbers in a way that it never goes beyond our end range when multiplied.

Now, before doing that, we need to add and subtract 1 G to our target and divide the results by 2, e.g. if our target is 256, we add 1, 2, 3, 4 etc and divide them all by 2 also we will add n/2 to all the results just to be safe and keep all of the keys to compare with our multiplication result.  Eventually if we change our nonce, ( 6 digit number ) enough times and multiply it with powers of 2, 3 etc somewhere we should see a known key.

A simple example :

Start range 1, end range 512, our target is 95, now we divide 512 by 32 to get 16.

But first lets generate some offsets for our target.

Add 1 to 95 = 96/2 = 48
Add 3 to 95 = 98/2 = 49
Add 5 to 95 = 100/2 = 50
Sub 1 from 95 = 94/2 = 47
Sub 15 from 95 = 80/2 = 40

Now we have 48, 49, 50, 47 and 40, then we multiply 16 by 2, 3, 4, 5, 6, 7, etc until we see one of the keys above.

Imagine if we generate different offsets, like billions of them, then we could simply keep multiplying to find one of our targets.


This just came to my mind today, it's not cooked well , yet!😉


I already tried and test it and much more that I don't remember but when someone refer it I already know how it will slap our ass  Grin!
The reason this and every similar approach won't work is strictly due to the modular behaviour of calculations!
Which is why BSGS Kangaroo has thus far been the best approach which is increasing the chances of luck and meet at middle! However, any other way around addition and subtraction would not work trust me, BECAUSE there is no full stop, when your calculations go pass around the curve and completes a circle, it actually passes your assumed mark,, funny thing is IT WON'T RING A BELL OR SHOW ANY ALERT!!!!!!!! It would still be showing you the point and you'll be happy assuming it as per your assumption but it would change itself from being ODD to EVEN, thats where everyone go nuts when things don't work as per assumptions, elliptically speaking LOL!!
[/quote]


hi brother, if you are a newbie here,, and you just have that idea today come to your mind, just put in your mind something, there is a lot of professional users here, we did think of all possibilities, dont you think that we already think of your idea ? of course we did think of  a lot , do you have the right materiel hardware to do that Huh if you do than ok we are with you lmao, its impossible to do it bro,
if you exctrat billions, still terramillions remains ...
newbie
Activity: 18
Merit: 0


Here is another idea, lets see if it can be done or has any merits to it.

If we know the exact start and end range of a public key, we could divide the end range by a number to reduce it down as much as possible, maybe making it a 6 digits number, now we only have to change our 6 digit number and multiply it by the number which we first divided our end range with, we need to change the numbers in a way that it never goes beyond our end range when multiplied.

Now, before doing that, we need to add and subtract 1 G to our target and divide the results by 2, e.g. if our target is 256, we add 1, 2, 3, 4 etc and divide them all by 2 also we will add n/2 to all the results just to be safe and keep all of the keys to compare with our multiplication result.  Eventually if we change our nonce, ( 6 digit number ) enough times and multiply it with powers of 2, 3 etc somewhere we should see a known key.

A simple example :

Start range 1, end range 512, our target is 95, now we divide 512 by 32 to get 16.

But first lets generate some offsets for our target.

Add 1 to 95 = 96/2 = 48
Add 3 to 95 = 98/2 = 49
Add 5 to 95 = 100/2 = 50
Sub 1 from 95 = 94/2 = 47
Sub 15 from 95 = 80/2 = 40

Now we have 48, 49, 50, 47 and 40, then we multiply 16 by 2, 3, 4, 5, 6, 7, etc until we see one of the keys above.

Imagine if we generate different offsets, like billions of them, then we could simply keep multiplying to find one of our targets.


This just came to my mind today, it's not cooked well , yet!😉

[/quote]

I already tried and test it and much more that I don't remember but when someone refer it I already know how it will slap our ass  Grin!
The reason this and every similar approach won't work is strictly due to the modular behaviour of calculations!
Which is why BSGS Kangaroo has thus far been the best approach which is increasing the chances of luck and meet at middle! However, any other way around addition and subtraction would not work trust me, BECAUSE there is no full stop, when your calculations go pass around the curve and completes a circle, it actually passes your assumed mark,, funny thing is IT WON'T RING A BELL OR SHOW ANY ALERT!!!!!!!! It would still be showing you the point and you'll be happy assuming it as per your assumption but it would change itself from being ODD to EVEN, thats where everyone go nuts when things don't work as per assumptions, elliptically speaking LOL!!
newbie
Activity: 18
Merit: 0


Really nice one, too bad I don't know how to run scripts, I'm just a windows person used to double click on exe files. 😅


Just copy the code and paste in notepad and save it as myscript.py (it would run on python), save in your folder, open folder, type CMD in address bar above and press ENTER, command prompt terminal will open, type there
>python myscript.py
and hit enter the script will run, you'll see step or jumps prints, chill!
copper member
Activity: 1330
Merit: 899
🖤😏
member
Activity: 239
Merit: 53
New ideas will be criticized and then admired.
newbie
Activity: 17
Merit: 0
I have a script that’s searching for the private key of puzzles 66,67, and 68. Just by just by searching through the hex range 20000000000000000 - 2ffffffffffffffff
Same can be done with the rest of the addresses. I only have to search through 1 range, but I can search for 4 addresses all at once.
So puzzle 68 may be cracked before 66 🤷‍♂️
If anyone is interested let me know. I will definitely need more computer power. But it’s worth it.. I’ve already tested it with previous addresses. Works like a charm. https://ibb.co/jzZTHhV
newbie
Activity: 18
Merit: 0

what are the parameters to put in place and what codes or tools would be required to achieve that goal mentioned above?
I'm not a code/tool expert, and I'm pretty sure all the existing ones lack something, I don't know maybe BSGS can do what I said.
If I had a perfect idea I could have used it myself, I only type what comes to my mind, whether it's possible or doable currently, I don't know. Hints is what I can provide the best.😉

Here is the code doing exactly what digaran explained earlier... I used on puzzle 125, chant it when someone else found it. I am not optimistic of it! you can have it if you've huge ram... it works on more more of a simple phenomenon rather then complex... In the script checkpoint.txt file has only public key x coordinates in decimal format. Why only x because, if you have public  keys of private keys from 1 to 1 billion, they are actually two billion public keys, first billion from 1 to 1 billion and the last billion,, both billion have same x coordinate,, so kind of really big help there Grin... The script first loads the file checkpoints.txt. so in this file I kept 80 million public keys from 2 - 80000000. The file size was 5.88 GB, been running on 8 GB RAM system. Here is how script works with a simple example you can modify relevant figures in script as per your needs...
Suppose our public key has the private key of 87 (which we don't know obviously) we have checkpoints from 1-5 (which is really big if we compare 80 million with 125 puzzle key distance),, so what the script does it, is subtracts a set jump from pubkey and checks the resulting point within checkpoints, you can set your own jump.. suppose you want to set jump size as 20, here is how script works:

87-20=67 (not in checkpoints)
67-20=47  (not in checkpoints)
47-20=27(not in checkpoints)
27-20=7(not in checkpoints)
7-20=-13(not in checkpoints)

As you know the range you can set the step size to suite the range, in our case, it is suitable to have 5 steps if we choose its size as 20...

After finishing 5 stepts, the script subtracts 5 from 87 and saves the progress in j_value.txt file, after every iteration it changes the value in j_value.txt file. So if you shutdown or power goes off, next time script restarts from where it left...
After first iteration script subtract 10 from 87-10=77
(10 because you have first 5 and last 5)
next iteration is like
77-20=57 (not in checkpoints)
57-20=37  (not in checkpoints)
37-20=17(not in checkpoints)
17-20=-3(matched)
-3 is matching because its inverse point is 3 and both have same x coordinate...
If a match is found, the script save that point in results.txt file.
I forget to mention xy.txt file has the decimal x and y coordinate of puzzle pub key.
Here is whole script: Chill
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 # These two defines the elliptic curve. y^2 = x^3 + Acurve * x + Bcurve
Gx = 55066263022277343669578718895168534326250603453777594175500187360389116729240
Gy = 32670510020758816978083085130507043184471273380659243275938904335757337482424
GPoint = (Gx,Gy) # This is our generator point. Trillions of dif ones possible

def modinv(a, n=Pcurve):
    lm, hm = 1, 0
    low, high = a % n, n
    while low > 1:
        ratio = high // low
        nm, new = hm - lm * ratio, high - low * ratio
        lm, low, hm, high = nm, new, lm, low
    return lm % n

def ECadd(a, b):
    if a == 'O':
        return b
    if b == 'O':
        return a
    if a == b:
        LamAdd = ((3 * a[0] * a[0] + Acurve) * modinv(2 * a[1], Pcurve)) % Pcurve
    else:
        LamAdd = ((b[1] - a[1]) * modinv(b[0] - a[0], Pcurve)) % Pcurve
    x = (LamAdd * LamAdd - a[0] - b[0]) % Pcurve
    y = (LamAdd * (a[0] - x) - a[1]) % Pcurve
    return (x, y)


def ECsub(a, b):
    if b == 'O':
        return a
    if isinstance(a, str):
        a = tuple(map(int, a.split()))
    if isinstance(b, str):
        b = tuple(map(int, b.split()))
    neg_b = (b[0], -b[1] % Pcurve)
    return ECadd(a, neg_b)


def ECmul(a, b):
    result = 'O'
    while b > 0:
        if b % 2 == 1:
            result = ECadd(result, a)
        a = ECadd(a, a)
        b = b // 2
    return result

# Read the x, y coordinates from xy.txt
with open("xy.txt", "r") as f:
    x, y = map(int, f.read().strip().split())
    point = (x, y)

# Read the checkpoint x-coordinates from checkpoints.txt
with open("checkpoints.txt", "r") as f:
    checkpoints = set(map(int, f.read().strip().split()))

filename_out = "results.txt"


sub_count = 0


# read the last value of j from file
try:
    with open("j_value.txt", "r") as f:
        last_j_value = int(f.readline())
except:
    last_j_value = 0

# loop for multiplication factor 0, 2, 4, 6, 8, 10, 12, 14, .......
found_match = False
for j in range(last_j_value, 10000001):
    if found_match:
        break
    sub_count = 160000000 * j
    for k in range(100001): # loop for 1lac subtract iterations
        if k == 0:  # first iteration
            pass
        else:
            sub_count += 212676479325586539664609129644855
        result = ECmul(GPoint, sub_count)
        result = ECsub(point, result)
        print(sub_count)
        if result[0] in checkpoints:
            with open(filename_out, "w") as f_out:
                subtractions = sub_count // 212676479325586539664609129644855
                f_out.write("{} {} {}".format(result[0], result[1], subtractions))
            found_match = True
            break
    # save the value of j to file after each iteration
    with open("j_value.txt", "w") as f:
        f.write(str(j))

7-20=-13(not in checkpoints)
jr. member
Activity: 69
Merit: 2
Well, the code using my strategy still needs something that I can't see now, but just like I saw the pattern with the powers of 2, I'm certain that I will see what's missing for it to be faster.

Currently, I will be working on #130, now that I finally understood how the BSGS works.
copper member
Activity: 1330
Merit: 899
🖤😏

what are the parameters to put in place and what codes or tools would be required to achieve that goal mentioned above?
I'm not a code/tool expert, and I'm pretty sure all the existing ones lack something, I don't know maybe BSGS can do what I said.
If I had a perfect idea I could have used it myself, I only type what comes to my mind, whether it's possible or doable currently, I don't know. Hints is what I can provide the best.😉
jr. member
Activity: 75
Merit: 5
Interesting!! However, in this case, you're not skipping keys; you're transposing the range from 2000:6000 to 1000:3000, which results in the same number of keys.

you avoid keys if you use the pubkey corresponding to pk 2, you would omit the odd private keys.
Why and how do you change the G? If you change the generator all the results will be incorrect for secp256k1 curve, maybe you mean to use a stride of 2, in order to skip 1 key between each jump,  or skip 2, well if you try that you will see that you are just skipping for example 33% of the range as well as reducing the probability of finding your target by 33%.

But there is a way to do the search for public key faster, first you need to subtract as many keys as you can to have a new and ideally small range key, then you could generate +1 billion offsets and -1 billion offsets to keep in a file for auto comparison, then you could use a stride in such a way that each stride never goes beyond 2 billion keys, that way you are certain each stride will definitely have a 100% chance of landing on one of the 2 billion saved public keys.

Now for someone with serious RAM and speed, they can generate +10 & -10 billion keys to check and use a bigger stride to search faster.😉

I am pretty much interested in generating these offsets as explained here, when you speaking of RAM sizes I can get as much as 5 Ekeys/s on BSGS with a good amount of thread too.

We need to know how to start and the BSGS is just an example to give you the understanding of the available RAM.

what are the parameters to put in place and what codes or tools would be required to achieve that goal mentioned above?
member
Activity: 239
Merit: 53
New ideas will be criticized and then admired.
Interesting!! However, in this case, you're not skipping keys; you're transposing the range from 2000:6000 to 1000:3000, which results in the same number of keys.

you avoid keys if you use the pubkey corresponding to pk 2, you would omit the odd private keys.
Why and how do you change the G? If you change the generator all the results will be incorrect for secp256k1 curve, maybe you mean to use a stride of 2, in order to skip 1 key between each jump,  or skip 2, well if you try that you will see that you are just skipping for example 33% of the range as well as reducing the probability of finding your target by 33%.

But there is a way to do the search for public key faster, first you need to subtract as many keys as you can to have a new and ideally small range key, then you could generate +1 billion offsets and -1 billion offsets to keep in a file for auto comparison, then you could use a stride in such a way that each stride never goes beyond 2 billion keys, that way you are certain each stride will definitely have a 100% chance of landing on one of the 2 billion saved public keys.

Now for someone with serious RAM and speed, they can generate +10 & -10 billion keys to check and use a bigger stride to search faster.😉

Code:
pk= 1
pub_x= 79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
pub_y= 483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8

pub_dec_x= 55066263022277343669578718895168534326250603453777594175500187360389116729240
pub_dec_y= 32670510020758816978083085130507043184471273380659243275938904335757337482424


These are the standard bitcoin parameters (secp256k1).

# Elliptic curve parameters (secp256k1)

Code:
P = 2**256 - 2**32 - 977
N = 115792089237316195423570985008687907852837564279074904382605163141518161494337
A = 0
B = 7
Gx = 55066263022277343669578718895168534326250603453777594175500187360389116729240
Gy = 32670510020758816978083085130507043184471273380659243275938904335757337482424
G = (Gx, Gy)

Gx & Gy  correspond to pubkey from pk #1

if we change these by the pubkey(x,y) of pk #2

Code:
pk= 2
pub_x= c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5
pub_y= 1ae168fea63dc339a3c58419466ceaeef7f632653266d0e1236431a950cfe52a

pub_dec_x= 89565891926547004231252920425935692360644145829622209833684329913297188986597
pub_dec_y= 12158399299693830322967808612713398636155367887041628176798871954788371653930

Code:
P = 2**256 - 2**32 - 977
N = 115792089237316195423570985008687907852837564279074904382605163141518161494337
A = 0
B = 7
Gx = 89565891926547004231252920425935692360644145829622209833684329913297188986597
Gy = 12158399299693830322967808612713398636155367887041628176798871954788371653930
G = (Gx, Gy)

we will get

Code:
pk=1
pub= 02c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5

pk=2
pub= 02e493dbf1c10d80f3581e4904930b1404cc6c13900ee0758474fa94abe8c4cd13

pk=3
pub= 03fff97bd5755eeea420453a14355235d382f6472f8568a18b2f057a1460297556


2, 4, 6....

that's what I mean.

And as for the decrease in the range of the pubkey, I'm on to something, which since you didn't understand before, I prefer to reserve it for the future.

copper member
Activity: 1330
Merit: 899
🖤😏
Interesting!! However, in this case, you're not skipping keys; you're transposing the range from 2000:6000 to 1000:3000, which results in the same number of keys.

you avoid keys if you use the pubkey corresponding to pk 2, you would omit the odd private keys.
Why and how do you change the G? If you change the generator all the results will be incorrect for secp256k1 curve, maybe you mean to use a stride of 2, in order to skip 1 key between each jump,  or skip 2, well if you try that you will see that you are just skipping for example 33% of the range as well as reducing the probability of finding your target by 33%.

But there is a way to do the search for public key faster, first you need to subtract as many keys as you can to have a new and ideally small range key, then you could generate +1 billion offsets and -1 billion offsets to keep in a file for auto comparison, then you could use a stride in such a way that each stride never goes beyond 2 billion keys, that way you are certain each stride will definitely have a 100% chance of landing on one of the 2 billion saved public keys.

Now for someone with serious RAM and speed, they can generate +10 & -10 billion keys to check and use a bigger stride to search faster.😉
member
Activity: 239
Merit: 53
New ideas will be criticized and then admired.
Interesting!! However, in this case, you're not skipping keys; you're transposing the range from 2000:6000 to 1000:3000, which results in the same number of keys.

you avoid keys if you use the pubkey corresponding to pk 2, you would omit the odd private keys.
jr. member
Activity: 69
Merit: 2
Interesting!! However, in this case, you're not skipping keys; you're transposing the range from 2000:6000 to 1000:3000, which results in the same number of keys.
member
Activity: 239
Merit: 53
New ideas will be criticized and then admired.
Folks, the focus shouldn't be on how many 1s or 0s bits keys should have; it should be on how to scan faster or how we can skip less probable keys.

If you want to play luck with #66 just change the parameter of the curve.

Code:
Gx = 55066263022277343669578718895168534326250603453777594175500187360389116729240
Gy = 32670510020758816978083085130507043184471273380659243275938904335757337482424
G = (Gx, Gy)

for example pub pk #2 (50-50 of probabilities)


Code:
Gy = 89565891926547004231252920425935692360644145829622209833684329913297188986597
Gy = 12158399299693830322967808612713398636155367887041628176798871954788371653930
G = (Gx, Gy)

or with any other pub to skip certain keys.

Please explain how to modify the parameters of the skip keys curve?

For example, the default parameter in the curve is this:

Code:
Gx = 55066263022277343669578718895168534326250603453777594175500187360389116729240
Gy = 32670510020758816978083085130507043184471273380659243275938904335757337482424
G = (Gx, Gy)

or in hex

Code:
Gx = 79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
Gy = 483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8


If we change this to this(pub key corresponding to private key #2):

Code:
Gx = 89565891926547004231252920425935692360644145829622209833684329913297188986597
Gy = 12158399299693830322967808612713398636155367887041628176798871954788371653930
G = (Gx, Gy)

hex
Code:
Gx = C6047F9441ED7D6D3045406E95C07CD85C778E4B8CEF3CA7ABAC09B95C709EE5
Gy  = 1AE168FEA63DC339A3C58419466CEAEEF7F632653266D0E1236431A950CFE52A


our search will go from 1,2,3,4,5,6,7..... to 2,4,6,8,10.....

if we want to search for a key in the range
Code:
2000:6000

we divide the range by 2

Code:
1000:3000

if we find the pk in 1024

multiply by 2 and this will be the original pk 2048

we would just skip odds.

if you use the pubkey from pk #3 then it would be sequence 3,6,9,12....
that is, 33.3% probability

jr. member
Activity: 69
Merit: 2
Folks, the focus shouldn't be on how many 1s or 0s bits keys should have; it should be on how to scan faster or how we can skip less probable keys.

If you want to play luck with #66 just change the parameter of the curve.

Code:
Gx = 55066263022277343669578718895168534326250603453777594175500187360389116729240
Gy = 32670510020758816978083085130507043184471273380659243275938904335757337482424
G = (Gx, Gy)

for example pub pk #2 (50-50 of probabilities)


Code:
Gy = 89565891926547004231252920425935692360644145829622209833684329913297188986597
Gy = 12158399299693830322967808612713398636155367887041628176798871954788371653930
G = (Gx, Gy)

or with any other pub to skip certain keys.

Please explain how to modify the parameters of the skip keys curve?
member
Activity: 239
Merit: 53
New ideas will be criticized and then admired.
Folks, the focus shouldn't be on how many 1s or 0s bits keys should have; it should be on how to scan faster or how we can skip less probable keys.

If you want to play luck with #66 just change the parameter of the curve.

Code:
Gx = 55066263022277343669578718895168534326250603453777594175500187360389116729240
Gy = 32670510020758816978083085130507043184471273380659243275938904335757337482424
G = (Gx, Gy)

for example pub pk #2 (50-50 of probabilities)


Code:
Gy = 89565891926547004231252920425935692360644145829622209833684329913297188986597
Gy = 12158399299693830322967808612713398636155367887041628176798871954788371653930
G = (Gx, Gy)

or with any other pub to skip certain keys.
Jump to: