Im a bit lost, you mean you create a code that can be run on mobile fast enough to search for the private key of a known public key within a limited search space?
It uses only cpu. If the search space is very limited, it is like you know already many bit of 256.
I'm saying:
for example, if you provide me:
1) a public key
2) the first 198 bit of the private key
then I can recover the last 58 bit of the key. Nothing more.
There is no magic, 58 bit is not so much. That is the meaning of the sentence: "the search space is very limited".
My code runs on a cpu. So I can use efficiently the Ram of my pc. Gpus are good for hashing computations, cpus are good for elliptic (multi integer precision, 256 bit in this case) computations.
I'll try a little explanation:
If I know already the first 255 bit, then the search space is 2 (the value for the right key ends with 0 or 1).
if I know already the first 254 bit, then the search space is 2^2 = 4
if I know already the first 246 bit, then the search space is 2^10 = 1024
With so small number, any cpu can in less than 1 sec retrieve the correct private key with brute force.
Now we talk about the key #57 of the puzzle transaction. We all know that the first 200 bit are 000000.....00001
then I search only the last 56 bit (between 2^56 and 2^57 - 1). With brute force I would need to use 2^56 different private keys to generate 2^56 public keys. Too much time. But If I knew only the address and not the public key, that would be the only way.
But If I know the public key too, then I can exploit an algebraic property of the elliptic curve (of all elliptic curves, not only the secp256k1). Then instead of doing 2^56 "computations", I need only to compute a list of 2^28 public keys, put it in Ram, then generate another list of 2^28 public keys and do a comparison between the 2 lists. In this way I get 2^58 combinations (that's the way the Baby Step Giant Step algorithm works). If you look at the links I provided in the previous post you can understand it better.
Input data:
private key #57 :
first 200 bit:
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001
public key (I got it from
https://www.blockchain.com/btc/tx/95b77d69302fbc805f1a6e97a3f0d27159017341e5f2d40ec79785d830fe9d59 -->
PUSHDATA(33)[02
a521a07e98f78b03fc1e039bc3a51408cd73119b5eb116e583fe57dc8db07aea], look at this
answer to understand how to get the y coordinate too)
x = a521a07e98f78b03fc1e039bc3a51408cd73119b5eb116e583fe57dc8db07aea
y = 6fb15c871dd7cf7d287390acd4e09d41f705081a98d5fe3a930ca032525dbcdc
Output data:
last 56 bit of the private key#57:
1101011001001011100100100000111100101011101011000011100
Now,
for the next private key #58:
Input data:
private key #58 :
first 199 bit:
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001
public key
x = ?
y = ?
Output data:
last 57 bit of the private key#58:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi. I probably misunderstood something.
In your example #57 (first 200 bit + last 56 bit) =
0000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000011101011001001011100100100000111100101
011101011000011100
HEX: 00000000000000000000000000000000000000000000000000eb25c90795d61c => 1J9zB6p4dRgyinst2eCVsyXvgYXtNhw2Y2
This is not a private key for #57
What did I miss?
