Author

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

jr. member
Activity: 54
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: 54
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: 107
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.😅
jr. member
Activity: 54
Merit: 1
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.
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.



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.
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.😴
member
Activity: 239
Merit: 53
New ideas will be criticized and then admired.
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 HuhHuhHuhHuh??
ECC and rmd160 are different, you won't find any similarity there.

the matches you find are just that, random matches.

hero member
Activity: 630
Merit: 731
Bitcoin g33k
can you try to be more specific, please? At best use a translator that will translate from your native language to english. I'm pretty sure this will be helpful for everyone. Oh, one more thing : try to give an -at least- one expressive example.
jr. member
Activity: 50
Merit: 1
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 HuhHuhHuhHuh??
hero member
Activity: 862
Merit: 662
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
copper member
Activity: 1330
Merit: 899
🖤😏
its not blind searching

03982a5a42895a5cfe4b9b98e49f9389ebf9b3bf91c2289f1c5db3d944f46ec710
hash160
3aaccf438388c4aeb0b433c7b778f25cb6ab244c


hash160
3aaccf438388c31f14410f489939d3d5eac88f19
pk: 48ea48b7a25627365cff38d

13 same hash160 digits, and its two substraction of 130 its not one substraction, 13 digits means its 80 pourcent in that range like puzzle 66

03982a5a42895a5cfe4b9b98e49f9389ebf9b3bf91c2289f1c5db3d944f46ec710 + 2786b52d106d22524ed9cf8a87d2
031ed6283a43d439eace1ee2815118cb6f16f475be60fa5ccc8598372d8c5f1995 # target

031ed6283a43d439eace1ee2815118cb6f16f475be60fa5ccc8598372d8c5f1995 # + 3.........................................
03633cbe3ec02b9401c5effa144c5b4d22f87940259634858fc7e59b1c09937852 # target

Can you show one example where you could find a key based on rmd160 similarities? I'd like to learn this non existing equation where we can estimate EC points range by finding rmd160 similar starting characters.


 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.
 
jr. member
Activity: 50
Merit: 1
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.😉



its not blind searching

03982a5a42895a5cfe4b9b98e49f9389ebf9b3bf91c2289f1c5db3d944f46ec710
hash160
3aaccf438388c4aeb0b433c7b778f25cb6ab244c


hash160
3aaccf438388c31f14410f489939d3d5eac88f19
pk: 48ea48b7a25627365cff38d

13 same hash160 digits, and its two substraction of 130 its not one substraction, 13 digits means its 80 pourcent in that range like puzzle 66

03982a5a42895a5cfe4b9b98e49f9389ebf9b3bf91c2289f1c5db3d944f46ec710 + 2786b52d106d22524ed9cf8a87d2
031ed6283a43d439eace1ee2815118cb6f16f475be60fa5ccc8598372d8c5f1995 # target

031ed6283a43d439eace1ee2815118cb6f16f475be60fa5ccc8598372d8c5f1995 # + 3.........................................
03633cbe3ec02b9401c5effa144c5b4d22f87940259634858fc7e59b1c09937852 # target



Jump to: