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.