Hi, is there a way to find private key range from the public key, (Start and Stop range) ? Can someone point me to the right direction
Topic: Pollard's kangaroo ECDLP solver - page 21. (Read 60037 times)
Can I ask about script python?
Each script and program Pollard's kangaroo ECDLP all are not the same algorithms right?
How can I know the same calculated algorithms?
Compare with calculating same public key and same keyspace search
https://github.com/JeanLucPons/Kangaroo
https://github.com/Telariust/pollard-kangaroo
https://github.com/secoc/Pollard-Rho-kangaroo
or compare with both python script
https://github.com/Telariust/pollard-kangaroo/blob/master/pollard-kangaroo-multi.py
https://github.com/BirminghamUK/Math_Task/blob/master/Recovery_X3.py
I test simply by use-value tame and wild that found the key to script python and swap value to another script it is now works value tame and wild can not use other script
Maybe I test the wrong way?
The you div 7 to 3 you get 2.5 = int2 float 0.5
7/3= 2.5
Then you sub 1 from 7 and div to 3 you get 2.
(7-1) / 3 = 2
So fo finding good range from 1 to 3, you need get EXACT integer without float.
But, why the I div
0xea1a5c66dcc11b5ad180 to 2**64 or 2**128 I always get some float result 0xea1a5c66dcc11b5ad180
7/3= 2.5
Then you sub 1 from 7 and div to 3 you get 2.
(7-1) / 3 = 2
So fo finding good range from 1 to 3, you need get EXACT integer without float.
But, why the I div
0xea1a5c66dcc11b5ad180 to 2**64 or 2**128 I always get some float result 0xea1a5c66dcc11b5ad180
paniker this is meaning that you can change the n's
modular elliptic curve
Total of all the wallets n is the last number. n= 115792089237316195423570985008687907852837564279074904382605163141518161494337 (In Dec)
n = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 (In HEX)
Half way of n n//2 = 57896044618658097711785492504343953926418782139537452191302581570759080747169
57896044618658097711785492504343953926418782139537452191302581570759080747169 Lenght Bits = 255
very nice and thanks to boris.. you still here..
modular elliptic curve
Total of all the wallets n is the last number. n= 115792089237316195423570985008687907852837564279074904382605163141518161494337 (In Dec)
n = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 (In HEX)
Half way of n n//2 = 57896044618658097711785492504343953926418782139537452191302581570759080747169
57896044618658097711785492504343953926418782139537452191302581570759080747169 Lenght Bits = 255
very nice and thanks to boris.. you still here..
yes I am still here, this was the only thing I have found so far.
Half way of n
n//2 is wrong, check in above posts, mention clearly formula for div
thankx
do you mean the last "6" ,
115792089237316195423570985008687907852837564279074904382605163141518161494337 ?
import gmpy
p = 115792089237316195423570985008687907852837564279074904382605163141518161494337
c = gmpy.invert(2,p) %p
print (c)
for div 10
import gmpy
p = 115792089237316195423570985008687907852837564279074904382605163141518161494337
c = gmpy.invert(10,p) %p
print (c)
same modify for your requirements
paniker this is meaning that you can change the n's
modular elliptic curve
Total of all the wallets n is the last number. n= 115792089237316195423570985008687907852837564279074904382605163141518161494337 (In Dec)
n = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 (In HEX)
Half way of n n//2 = 57896044618658097711785492504343953926418782139537452191302581570759080747169
57896044618658097711785492504343953926418782139537452191302581570759080747169 Lenght Bits = 255
very nice and thanks to boris.. you still here..
modular elliptic curve
Total of all the wallets n is the last number. n= 115792089237316195423570985008687907852837564279074904382605163141518161494337 (In Dec)
n = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 (In HEX)
Half way of n n//2 = 57896044618658097711785492504343953926418782139537452191302581570759080747169
57896044618658097711785492504343953926418782139537452191302581570759080747169 Lenght Bits = 255
very nice and thanks to boris.. you still here..
yes I am still here, this was the only thing I have found so far.
Half way of n
n//2 is wrong, check in above posts, mention clearly formula for div
thankx
do you mean the last "6" ,
115792089237316195423570985008687907852837564279074904382605163141518161494337 ?
There seems to be some confusion here. the largest possible private key is 115792089237316195423570985008687907852837564279074904382605163141518161494336 or in hex FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140
Zero cannot be a private key therefor there are 115,792,089,237,316,195,423,570,985,008,687,907,852,837,564,279,074,904,382,605,163,141,518,161,494,336 valid private keys
It turns out there are only 57,896,044,618,658,097,711,785,492,504,343,953,926,418,782,139,537,452,191,302,581,570,759,080,747,168 valid public x coordinates
It really is not straight forward to grasp as it took me time though it happens at half of the largest key which is 57896044618658097711785492504343953926418782139537452191302581570759080747168 or in hex 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0
you see 57.........168 and 57.........169 have both the same public x coordinate and opposite y parity (fancy word for even/odd)
removing the lead 03 or 02 It turns out that every public x coord from 1 to 57.........168 is exactly equal to the public x coord at the same spot in the sequence from 115........336 to 57.........169
finally, if you search every private key from 1 to 57,896,044,618,658,097,711,785,492,504,343,953,926,418,782,139,537,452,191,302,581,570,759,080,747,168 (exactly half the normal range) for a public x coord (the majority of a compressed public key) you would find it whether or not the original private key was larger or smaller than 57.........169 however a leading 03 would be 02 and vice versa therefor the limitation doesn't apply to the resulting addresses. In a sense the only thing we care about a private key with this equation is the position of the xcoord's "foundkey" 1 + (115........336-foundkey) or 115........336 - (foundkey-1) depending on which side of 57.........168.5 the foundkey is as we can infer the other and deduce the private key.
In other words this would cut the time of brute forcing any public key in half provided you are searching the full range of 1 to 115........336.
57.........168 is still a lot of private keys so bitcoin is not exactly broken.....yet.
Also with regards to the y value,
What I mean when I say "it is trivial to calculate the y" value I am referencing the following information I had apparently left out, from the spec of Secp256k1
p = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F = 2^256 - 2^32 - 2^9 - 2^8 - 2^7 - 2^6 - 2^4 - 1 (115792089237316195423570985008687907853269984665640564039457584007908834671663)
the aforementioned "twins" that share a public x coord also share a y coords in the manner that they are linked together as adding the two y coords together = p (115792089237316195423570985008687907853269984665640564039457584007908834671663)
therefor it can be computed as following
p - y1 = y2
deriving from my earlier code you can try it with this:
for x in range(100000):
s1 = secrets.randbelow(max)
k = Key.from_int(s1)
k._public_key = k._pk.public_key.format(compressed=False)
s2 = twin(s1,k.pub_to_hex())
t = Key.from_int(s2[0])
t._public_key = t._pk.public_key.format(compressed=False)
out = bool(115792089237316195423570985008687907853269984665640564039457584007908834671663 == int(t.pub_to_hex()[66:],16)+int(k.pub_to_hex()[66:],16))
print(out)
if not out:
print("Boris Is Wrong")
break
paniker this is meaning that you can change the n's
modular elliptic curve
Total of all the wallets n is the last number. n= 115792089237316195423570985008687907852837564279074904382605163141518161494337 (In Dec)
n = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 (In HEX)
Half way of n n//2 = 57896044618658097711785492504343953926418782139537452191302581570759080747169
57896044618658097711785492504343953926418782139537452191302581570759080747169 Lenght Bits = 255
very nice and thanks to boris.. you still here..
modular elliptic curve
Total of all the wallets n is the last number. n= 115792089237316195423570985008687907852837564279074904382605163141518161494337 (In Dec)
n = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 (In HEX)
Half way of n n//2 = 57896044618658097711785492504343953926418782139537452191302581570759080747169
57896044618658097711785492504343953926418782139537452191302581570759080747169 Lenght Bits = 255
very nice and thanks to boris.. you still here..
yes I am still here, this was the only thing I have found so far.
Half way of n
n//2 is wrong, check in above posts, mention clearly formula for div
thankx
do you mean the last "6" ,
115792089237316195423570985008687907852837564279074904382605163141518161494337 ?
There seems to be some confusion here. the largest possible private key is 115792089237316195423570985008687907852837564279074904382605163141518161494336 or in hex FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140
Zero cannot be a private key therefor there are 115,792,089,237,316,195,423,570,985,008,687,907,852,837,564,279,074,904,382,605,163,141,518,161,494,336 valid private keys
It turns out there are only 57,896,044,618,658,097,711,785,492,504,343,953,926,418,782,139,537,452,191,302,581,570,759,080,747,168 valid public x coordinates
It really is not straight forward to grasp as it took me time though it happens at half of the largest key which is 57896044618658097711785492504343953926418782139537452191302581570759080747168 or in hex 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0
you see 57.........168 and 57.........169 have both the same public x coordinate and opposite y parity (fancy word for even/odd)
removing the lead 03 or 02 It turns out that every public x coord from 1 to 57.........168 is exactly equal to the public x coord at the same spot in the sequence from 115........336 to 57.........169
finally, if you search every private key from 1 to 57,896,044,618,658,097,711,785,492,504,343,953,926,418,782,139,537,452,191,302,581,570,759,080,747,168 (exactly half the normal range) for a public x coord (the majority of a compressed public key) you would find it whether or not the original private key was larger or smaller than 57.........169 however a leading 03 would be 02 and vice versa therefor the limitation doesn't apply to the resulting addresses. In a sense the only thing we care about a private key with this equation is the position of the xcoord's "foundkey" 1 + (115........336-foundkey) or 115........336 - (foundkey-1) depending on which side of 57.........168.5 the foundkey is as we can infer the other and deduce the private key.
In other words this would cut the time of brute forcing any public key in half provided you are searching the full range of 1 to 115........336.
57.........168 is still a lot of private keys so bitcoin is not exactly broken.....yet.
paniker this is meaning that you can change the n's
modular elliptic curve
Total of all the wallets n is the last number. n= 115792089237316195423570985008687907852837564279074904382605163141518161494337 (In Dec)
n = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 (In HEX)
Half way of n n//2 = 57896044618658097711785492504343953926418782139537452191302581570759080747169
57896044618658097711785492504343953926418782139537452191302581570759080747169 Lenght Bits = 255
very nice and thanks to boris.. you still here..
modular elliptic curve
Total of all the wallets n is the last number. n= 115792089237316195423570985008687907852837564279074904382605163141518161494337 (In Dec)
n = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 (In HEX)
Half way of n n//2 = 57896044618658097711785492504343953926418782139537452191302581570759080747169
57896044618658097711785492504343953926418782139537452191302581570759080747169 Lenght Bits = 255
very nice and thanks to boris.. you still here..
yes I am still here, this was the only thing I have found so far.
Half way of n
n//2 is wrong, check in above posts, mention clearly formula for div
thankx
do you mean the last "6" ,
115792089237316195423570985008687907852837564279074904382605163141518161494337 ?
paniker this is meaning that you can change the n's
modular elliptic curve
Total of all the wallets n is the last number. n= 115792089237316195423570985008687907852837564279074904382605163141518161494337 (In Dec)
n = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 (In HEX)
Half way of n n//2 = 57896044618658097711785492504343953926418782139537452191302581570759080747169
57896044618658097711785492504343953926418782139537452191302581570759080747169 Lenght Bits = 255
very nice and thanks to boris.. you still here..
modular elliptic curve
Total of all the wallets n is the last number. n= 115792089237316195423570985008687907852837564279074904382605163141518161494337 (In Dec)
n = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 (In HEX)
Half way of n n//2 = 57896044618658097711785492504343953926418782139537452191302581570759080747169
57896044618658097711785492504343953926418782139537452191302581570759080747169 Lenght Bits = 255
very nice and thanks to boris.. you still here..
yes I am still here, this was the only thing I have found so far.
Half way of n
n//2 is wrong, check in above posts, mention clearly formula for div
thankx
paniker this is meaning that you can change the n's
modular elliptic curve
Total of all the wallets n is the last number. n= 115792089237316195423570985008687907852837564279074904382605163141518161494337 (In Dec)
n = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 (In HEX)
Half way of n n//2 = 57896044618658097711785492504343953926418782139537452191302581570759080747169
57896044618658097711785492504343953926418782139537452191302581570759080747169 Lenght Bits = 255
very nice and thanks to boris.. you still here..
modular elliptic curve
Total of all the wallets n is the last number. n= 115792089237316195423570985008687907852837564279074904382605163141518161494337 (In Dec)
n = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 (In HEX)
Half way of n n//2 = 57896044618658097711785492504343953926418782139537452191302581570759080747169
57896044618658097711785492504343953926418782139537452191302581570759080747169 Lenght Bits = 255
very nice and thanks to boris.. you still here..
yes I am still here, this was the only thing I have found so far.
paniker this is meaning that you can change the n's
modular elliptic curve
Total of all the wallets n is the last number. n= 115792089237316195423570985008687907852837564279074904382605163141518161494337 (In Dec)
n = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 (In HEX)
Half way of n n//2 = 57896044618658097711785492504343953926418782139537452191302581570759080747169
57896044618658097711785492504343953926418782139537452191302581570759080747169 Lenght Bits = 255
very nice and thanks to boris.. you still here..
modular elliptic curve
Total of all the wallets n is the last number. n= 115792089237316195423570985008687907852837564279074904382605163141518161494337 (In Dec)
n = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 (In HEX)
Half way of n n//2 = 57896044618658097711785492504343953926418782139537452191302581570759080747169
57896044618658097711785492504343953926418782139537452191302581570759080747169 Lenght Bits = 255
very nice and thanks to boris.. you still here..
I found a method to find any private key within 2^255 bit space. Is that new?
Can you tells us more about it?))
Absolutely, so it seems that the amount of valid public x-coords is exactly half the amount of private keys.
So as the theory is any key in the full range (1-115792089237316195423570985008687907852837564279074904382605163141518161494336 ~2^256) either it is less than half (57896044618658097711785492504343953926418782139537452191302581570759080747168) or has the same x coordinate as one that does (above 57896044618658097711785492504343953926418782139537452191302581570759080747169).
I have a mathematical function to find the resulting twin on either side.
I really do like the work that has been done here on the Kangaroo software so I will provide my python function for reference of finding said twin so long as you know 1 of 2 private keys you will know both.
~2^255 is still a very large number.
In the case of uncompressed keys you still have to compute the y coord after but it is trivial.
(using the bit library for python as the function is not intensive)
from bit import Key
import secrets
def twin(i, pubhex):
max = 115792089237316195423570985008687907852837564279074904382605163141518161494336
if len(pubhex) == 66:
publichex = str(pubhex)[2:66]
if i < 57896044618658097711785492504343953926418782139537452191302581570759080747169:
twin = max - (i-1)
if str(pubhex)[:2] == '02':
twinprefix = '03'
return [twin,f'{twinprefix}{publichex}']
elif str(pubhex)[:2] == '03':
twinprefix = '02'
return [twin, f'{twinprefix}{publichex}']
elif i > 57896044618658097711785492504343953926418782139537452191302581570759080747168:
twin = 1 + (max-i)
if str(pubhex)[:2] == '02':
twinprefix = '03'
return [twin,f'{twinprefix}{publichex}']
elif str(pubhex)[:2] == '03':
twinprefix = '02'
return [twin,f'{twinprefix}{publichex}']
elif len(pubhex) == 130:
publichex = str(pubhex)[2:66]
if i < 57896044618658097711785492504343953926418782139537452191302581570759080747169:
twin = max - (i-1)
return [twin,f'uncomp,{publichex}']
elif i > 57896044618658097711785492504343953926418782139537452191302581570759080747168:
twin = 1 + (max-i)
return [twin, f'uncomp,{publichex}']
max = 115792089237316195423570985008687907852837564279074904382605163141518161494336
for x in range(100):
q = secrets.randbelow(max)
k = Key.from_int(x)
t = twin(x,k.pub_to_hex())
pt = t[0]
ptpub = Key.from_int(pt).pub_to_hex()
print(t[1],ptpub)
'''
# Or you can do this
for x in range(1000):
x = secrets.randbelow(max)
k = Key.from_int(x)
t = twin(x,k.pub_to_hex())
pt = t[0]
ptpub = Key.from_int(pt).pub_to_hex()
assert t[1] == ptpub
'''
'''
# for uncompressed
for x in range(100000):
x = secrets.randbelow(max)
k = Key.from_int(x)
k._public_key = k._pk.public_key.format(compressed=False)
t = twin(x,k.pub_to_hex())
pt = Key.from_int(t[0])
# this next line is not nessicary as we format the response without the leading '04'
pt._public_key = pt._pk.public_key.format(compressed=False)
ptpub = pt.pub_to_hex()
assert t[1] == f'uncomp,{str(ptpub)[2:66]}'
'''
Hi still not understand how it works and whats doing, donot understand big numbers, not all of them
I found a method to find any private key within 2^255 bit space. Is that new?
Tell us if you've already decided to brag
Upd. Better yet, just prove it. I generated a random key. Here is the public key for it
0337aff652dd11e2870636b0c4ce4fb324f4b0df45e70f7d8c77d15fcc9ae73525
I would have to know the key for 0237aff652dd11e2870636b0c4ce4fb324f4b0df45e70f7d8c77d15fcc9ae73525 as it would we below ~2^255 if 0337aff652dd11e2870636b0c4ce4fb324f4b0df45e70f7d8c77d15fcc9ae73525 is above.
I found a method to find any private key within 2^255 bit space. Is that new?
Can you tells us more about it?))
Absolutely, so it seems that the amount of valid public x-coords is exactly half the amount of private keys.
So as the theory is any key in the full range (1-115792089237316195423570985008687907852837564279074904382605163141518161494336 ~2^256) either it is less than half (57896044618658097711785492504343953926418782139537452191302581570759080747168) or has the same x coordinate as one that does (above 57896044618658097711785492504343953926418782139537452191302581570759080747169).
I have a mathematical function to find the resulting twin on either side.
I really do like the work that has been done here on the Kangaroo software so I will provide my python function for reference of finding said twin so long as you know 1 of 2 private keys you will know both.
~2^255 is still a very large number.
In the case of uncompressed keys you still have to compute the y coord after but it is trivial.
(using the bit library for python as the function is not intensive)
from bit import Key
import secrets
def twin(i, pubhex):
max = 115792089237316195423570985008687907852837564279074904382605163141518161494336
if len(pubhex) == 66:
publichex = str(pubhex)[2:66]
if i < 57896044618658097711785492504343953926418782139537452191302581570759080747169:
twin = max - (i-1)
if str(pubhex)[:2] == '02':
twinprefix = '03'
return [twin,f'{twinprefix}{publichex}']
elif str(pubhex)[:2] == '03':
twinprefix = '02'
return [twin, f'{twinprefix}{publichex}']
elif i > 57896044618658097711785492504343953926418782139537452191302581570759080747168:
twin = 1 + (max-i)
if str(pubhex)[:2] == '02':
twinprefix = '03'
return [twin,f'{twinprefix}{publichex}']
elif str(pubhex)[:2] == '03':
twinprefix = '02'
return [twin,f'{twinprefix}{publichex}']
elif len(pubhex) == 130:
publichex = str(pubhex)[2:66]
if i < 57896044618658097711785492504343953926418782139537452191302581570759080747169:
twin = max - (i-1)
return [twin,f'uncomp,{publichex}']
elif i > 57896044618658097711785492504343953926418782139537452191302581570759080747168:
twin = 1 + (max-i)
return [twin, f'uncomp,{publichex}']
max = 115792089237316195423570985008687907852837564279074904382605163141518161494336
for x in range(100):
q = secrets.randbelow(max)
k = Key.from_int(x)
t = twin(x,k.pub_to_hex())
pt = t[0]
ptpub = Key.from_int(pt).pub_to_hex()
print(t[1],ptpub)
'''
# Or you can do this
for x in range(1000):
x = secrets.randbelow(max)
k = Key.from_int(x)
t = twin(x,k.pub_to_hex())
pt = t[0]
ptpub = Key.from_int(pt).pub_to_hex()
assert t[1] == ptpub
'''
'''
# for uncompressed
for x in range(100000):
x = secrets.randbelow(max)
k = Key.from_int(x)
k._public_key = k._pk.public_key.format(compressed=False)
t = twin(x,k.pub_to_hex())
pt = Key.from_int(t[0])
# this next line is not nessicary as we format the response without the leading '04'
pt._public_key = pt._pk.public_key.format(compressed=False)
ptpub = pt.pub_to_hex()
assert t[1] == f'uncomp,{str(ptpub)[2:66]}'
'''
I found a method to find any private key within 2^255 bit space. Is that new?
Tell us if you've already decided to brag
Upd. Better yet, just prove it. I generated a random key. Here is the public key for it
0337aff652dd11e2870636b0c4ce4fb324f4b0df45e70f7d8c77d15fcc9ae73525
I found a method to find any private key within 2^255 bit space. Is that new?
Fake! Don't trust anything like this. I found a method to find any private key within 2^255 bit space. Is that new?
Depends on what the method is, what is the method?
I found a method to find any private key within 2^255 bit space. Is that new?
Can you tells us more about it?))
I found a method to find any private key within 2^255 bit space. Is that new?
Hi
I can eventually convert this code using my own secp256k1 library for CUDA (based on Jean Luc Pons Kangaroo ).
It can achieve up to 70M scalar mult /sec on a rtx 3070.
A python implementation with pycuda can be do easily
But sorry for this trivial question :
What the purpose of this script?
Regards
Fanch
I can eventually convert this code using my own secp256k1 library for CUDA (based on Jean Luc Pons Kangaroo ).
It can achieve up to 70M scalar mult /sec on a rtx 3070.
A python implementation with pycuda can be do easily
But sorry for this trivial question :
What the purpose of this script?
Regards
Fanch
using 120 puzzles public key to generate a lot of keys and use that script random the more keys the better the chance to hit one
I just don't know if it can be generated with 1 public key more keys if so, it can be useful
I've redesigned it a bit now, I should , 2x faster for python
Hi
I already think about this method of searching for a collision between a temporary key (for example every intermediate wild kangaroo jump) and a lookup in a hashtable of precomputed random key in the range of puzzle 120.
Let-s do some math to show if it is realistic or not...
Imagine that you will precompute an huge hashtable (or a bloom filter) of 256 Gigas entries (or 256Giga keys picked up at random in the puzzle 120 interval)
Forget the fact that this table will occupe several TerraBytes of RAM and that the lookup time will increases with the size of the hashtable (less true for a bloom filter look up).
The formula which defines the probability of finding a particular piece among N pieces at the end of n draw without replacement, is as follows:
P=1-(1-1/N)^n
we can replace 1/N by (number_entries_in_hashtable/interval_of_puzzle_120) = 256*10^9/(2^120-2^119) = 3.85e-25
We fixed for example P=0.5 (means a probability of having an hit of 50%)
Let's calculate n for such P=0.5
0.5=(1-1/N)^n
a=b^n => n=ln(a)/ln(b)
n=ln(0.5)/ln(1-3.85e-25) = 1.8e24
if your GPU can do 1 billion jumps (and lookup at the same time) per second (typically the speed of Jean-Luc pons program with a good GPU)
You will have to wait 1.8e24/1e9 = 1.8e15 seconds or 57 Millions of years before having 50% of having an hit...
Hopeless..., even if you uses a bigger hashtable or a powerfull GPU cloud.
The main problem of this approach is that you don't profite of the birthday paradox used in the kangaroo solver because you look for in a predefined list.
Regards
Fanch
d i don't know now i have pasted this code for funfrom bit import Key
for xx in range(1):
q = 1
for x in range(200):
for y in range(170,200):
probability = x / y
q *= (1 - probability)
p = 1 - q
for cc in range(922,1845):
x0 = ''.join(str(cc))
x1 = ''.join(str(p))[2:]
ke = Key.from_int(int(x0+x1))
if (str(ke)).endswith("QN>"): # this print all bitcoin address they end big N> use this XQN> code run faster
print(x0+x1,ke,x,y)
if (str(ke)) == "
f=open("win.txt","a")
f.write(str(x0+x1)+(str(ke))+"\n")
f.close()
Hello i was playing with reverse brut on 62-63? but not so fast as they found it it interesting
i try to change ranges in:
(for y in range(170,200)
( for cc in range(922,1845): )
and got strange results.
only even numbers on end (...99679470) (..00198327750)
and it's going not random, searching 1 by1
Jean_Luc made his last post on October 11, 2020, and he was last active July 28, 2021 (more than 6 months ago). His last commits on github were also a year ago (February 2021)
Is everything ok with TC? (Jean_Luc)
Is everything ok with TC? (Jean_Luc)
I think he is just not interested anymore, as #120 seems to be unsolvable in reasonable time with the current software & hardware.
I do not know, maybe there were other tensions, maybe some users wanted to use him as a free source of tools to crack bitcoin. No idea, but reading his topics I see there were many demanding ignorant.
Or maybe he is still here, using other account. Who knows.
Jump to: