Since I don't have the resources to hope to compete here and everyone else is likely frantically converting pubkeys into byte arrays and re-writing thier stuff... 
So anyway the breakshort program uses the baby step giant step algo and the public key ( https://en.wikipedia.org/wiki/Baby-step_giant-step ) to basically cut the searching down to the squareroot but it is ram intensive (like build a hashtable that can hold 2^80 and it can then search 2^160 and that is VERY cool, BUT the sheer ram needed to do something like that doesn't exist at the moment. ) say you have 8gb ram you can do maybe* 2^27 in the hashtable which seems to search "about" 2^55 keyspace - in a freakishly short amount of time. Kinda awesome right? say you wanna do 2^28 hashtable.. now you just doubled memory requirements.
* maybe is because of certain variables.. like the breakshort program as is, you can in theory do 2^29? (i think) with 8gb but with unint32_t you have potential for false collisions - and on my comp for some reason while 2^28 "should" work fine - 2^27 takes 52% mem so if I try 2^28 it starts using the swap file and SIGNIFICANTLY slowing it down. you figure that 4% wouldn't be THAT big a deal but it is the difference between driving a car a mile vs riding a skateboard a mile and a half. All over this thread is all kinds of info that is far more informative than I'm being - look around, have fun with it. (seriously I started out as "What?!?! free bitcoin!!! and then got sucked into teaching myself C (With quite a bit of help - you know who you are and thank you again) At my age this is kind of a "thing" - and going from not having a clue what an elliptic curve is to being fascinated by cryptography (well okay that whole journey started in 2012? 13? when my son first said the word bitcoin and I was like "Huh?" ) -:) anyway go back as many pages as you need to and happy hunting.
@arulbero can you tell us how you found it? details on how you used baby-step giant-step algorithm
can you explain in short why the size of RAM matters in this algorithm?
I thought it just generates privkey hex sequentially, finds corresponding pubkey and compares it to target pubkey
So anyway the breakshort program uses the baby step giant step algo and the public key ( https://en.wikipedia.org/wiki/Baby-step_giant-step ) to basically cut the searching down to the squareroot but it is ram intensive (like build a hashtable that can hold 2^80 and it can then search 2^160 and that is VERY cool, BUT the sheer ram needed to do something like that doesn't exist at the moment. ) say you have 8gb ram you can do maybe* 2^27 in the hashtable which seems to search "about" 2^55 keyspace - in a freakishly short amount of time. Kinda awesome right? say you wanna do 2^28 hashtable.. now you just doubled memory requirements. * maybe is because of certain variables.. like the breakshort program as is, you can in theory do 2^29? (i think) with 8gb but with unint32_t you have potential for false collisions - and on my comp for some reason while 2^28 "should" work fine - 2^27 takes 52% mem so if I try 2^28 it starts using the swap file and SIGNIFICANTLY slowing it down. you figure that 4% wouldn't be THAT big a deal but it is the difference between driving a car a mile vs riding a skateboard a mile and a half. All over this thread is all kinds of info that is far more informative than I'm being - look around, have fun with it. (seriously I started out as "What?!?! free bitcoin!!! and then got sucked into teaching myself C (With quite a bit of help - you know who you are and thank you again) At my age this is kind of a "thing" - and going from not having a clue what an elliptic curve is to being fascinated by cryptography (well okay that whole journey started in 2012? 13? when my son first said the word bitcoin and I was like "Huh?" ) -:) anyway go back as many pages as you need to and happy hunting.
arulbero
It seems that someone is doing something very odd here. the above recent transaction https://www.blockchain.com/de/btc/tx/17e4e323cfbc68d7f0071cad09364e8193eedf8fefbcbd8a21b4b65717a4b3d3
~
Who else other than puzzle owner can spend from theses wallets??
I think that's the reason he can find #65 private key, exposed public key makes it easier It seems that someone is doing something very odd here. the above recent transaction https://www.blockchain.com/de/btc/tx/17e4e323cfbc68d7f0071cad09364e8193eedf8fefbcbd8a21b4b65717a4b3d3
~
Who else other than puzzle owner can spend from theses wallets??
@arulbero can you tell us how you found it? details on how you used baby-step giant-step algorithm
I think that beyond #85 it will be very difficult to recover the private key, even with 1 TB of RAM (with the Baby-Giant Step algorithm).
With my 32 GB finding the #70 is already a hard task.
But there are other algorithms more suitable that don't need so much ram.
I don't understand thoroughly the algorithm With my 32 GB finding the #70 is already a hard task.
But there are other algorithms more suitable that don't need so much ram.
can you explain in short why the size of RAM matters in this algorithm?
I thought it just generates privkey hex sequentially, finds corresponding pubkey and compares it to target pubkey