The  new  version  is  finally  ready.  You  can  download  PhoenixMiner  5.8a  from  here:

PhoenixMiner_5.8a_Windows.zip Github
PhoenixMiner_5.8a_Linux.tar.gz Github


Changes in version 5.8a :

• LHR disable mode -lhrdis <n>  1 - yes (default), 0 - no
• Added lock core clock
• Fixed an issue causing crashing with some RTX 3060/3080/3090 cards
• Implemented new "turbo" kernels (-clkernel 3) for AMD Polaris cards that can work with the current DAG sizes over 4 GB. Note that -clkernel 3 uses double the VRAM and will
  provide slightly faster hashrate with slightly higher power consumption. You can use the -rvram command-line parameter to specify how much VRAM to be left unused
• Increased the maximum supported DAG epoch to 600 (i.e. until about Sep 2023)
• Implemented full hardware control for AMD RX6900/6800/6700 cards under Linux. Note that with these cards under Linux you need to specify relative core voltage: e.g. -
  cclock -50 will set the core voltage to be 50 mV under the default value
• Added ROCr kernels for Vega, Radeon VII and Navi cards. With these kernels you will be able to run these cards with Linux drivers 20.45 and later but the performance will
  be lower than with the older PAL drivers and kernels. We recommend using AMD Linux driver 20.30 for all cards except RX6900/6800/6700
• Fixed an issue causing crashing with some RX6900/6800/6700 cards under Linux (there is no need to run these cards with -clkernel 0 anymore)
• Added support for AMD Windows drivers up to 21.8.1. Note that Radeon VII cards will not work with drivers 21.6.1 or higher - you need to use older drivers for proper
  operation of these cards
• Added support for AMD Linux drivers up to 21.20 (use older drivers for Vega or Radeon VII cards as they will not work with 21.20). Note that the latest 21.30 drivers are
  not supported (and the initial testing shows that even the older Polars cards are not working properly with them, so avoid 21.30 for now)
• Numerous other fixes and small improvements

Please let us know if you have any problems or questions related to PhoenixMiner 5.8a

While not part of the puzzle, but having a bit to do with why it was created in the first place.. an interesting exercise  no reward other than knowledge though I'll probably put a pi with a randomizied python script on it. finding a collision for the first two in the puzzle and see how far apart they are, might give a "clearer view" of the curve if that makes any sense. - Though that would probably end up being harder than finding #160 - Still, worth thinking about.

Hehe It never even crossed my mind to import bitcoin - much better!

a python script to turn compressed into umcompressed pubkey



Then converting to dec should be no biggie in python
blah=0xwhatever (x co-ord, then y maybe?)
print (blah)

Now you have the numbers put them in whatever program in whatever language you are working with..

This is possibly the silliest thing I have read today. - if the owner decided to take the btc it would all already be gone. if he (guessing but the odds are 'he') wanted his friends to have it... same.. poof.. gone...  - the something that you believe (still not sure what that is btw- but a guess is to follow) that you will believe differently when you find a private key etc... I'm guessing is some sort of strange conspiracy where a guy takes a hundred billfolds with money in them, hides them all over the place and goes "find them" but secretly tells his friends where they are.. umm a) - why not just hand over some bills to your pal bob? b) why... like why the whole thing at all?  c) if that was the case, owner/friends would go get the 1.6 immediately.   -as a sidenote, but only slightly to the side... somewhere the owner spoke up and was talking about it being a way to encourage people to see what they can do towards figuring out ways around the cryptography, thus proving/disproving the "safety" of your coins. As we have seen, so long as you didn't use reaaaaally low entropy keys, and so long as you don't reuse an address you are fairly okay (so far) but keep using the same address and you are asking for trouble... maybe not fast trouble.. but trouble none-the-less. (It is my personal belief that the move revealing the pubkeys was prompted by all the talk about programs to get the private key from public and he was like "well hey let's see what they can really do here..." (otherwise why skip by five...) Now if you want a plausible conspiracy - which doesn't really take away from the "puzzle" so much as show a human side to things.. let's say bob creates puzzle when btc is cheap as dirt.. time goes on.. btc gets really up there.. bob has a hospital bill/car trouble/baby on the way etc.. whatever... people are popping off with prv key from pub, he needs a little something... but more than .62 so move.. and grab the first one.. still giving others a shot  (This imho is still VERY unlikely.. 'cause as we know he already has all the keys.. could take whenever he likes. so really he could have just snagged it all and walked away if he needed cash, so he really wants people to strive for better/shorter ways or similar to the lbc show exactly how hard this would be to do... the harder it is btw the more acceptable it is to joe public even though they will never REALLY understand that it is ALREADY harder even with low entropy to get a priv key than it is to get into their bank account - or their atm pin which is likely to be a family member's b-day anniversary or some foolish stuff like that.)
There is my 5 satoshi. inflation yo.

#90 just moved.

Just for a fun little "thing" : for those frustrated by how long this takes.. someone could sort out how long it would take with a gpu and bitcrack and now it suddenly looks like a month is no big deal.

32/33/34 (read back a bit each increase doubles the memory requirement)
and as we have seen if the 512 does not have 512 of actual usable ram you need to go down one
(i.e. if it really has say 500 available then 33 it is.. but will only use 256gb)

Think that through a moment.

-bad analogy but close enough-
A: my backpack won't hold this.
B: try this (insert advice)...
A: Nah man I got a 64# backpack (which holds 62.8#) plus a fanny pack that holds 8# (why can't I put this 64# block in my backpack?!?!)

C: "Try the advice."


Just as an aside the reason my "8gb" doesn't do gstep 28 (using uint64 on hash entries) is apparently a built in video card is sharing some memory so it has 7.something gb so I can only go to 27 gstep.  - have an 8gb swap as well - the comp just looks at me and says explative please.

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.

well waddn't me *sigh* I have been "working ahead" because of lack of hardware, but alot of randomness and set spaced skipping is what I'm doing with some raspberry pi's ...figured hey... they don't use that much electricity right? but looks like some others are doing the same so going to go with pure random per keyspace since I don't have any chance otherwise(anyways? hehe) maybe the old irish luck will kick in for me here.

Much further back he talked about how the prog (in your link) uses uint32_t which has a significant chance of causing false positives. to get 65 you'd have to be able to do at least 1<<32.  if you do uint64_t (the hashtable wil take up more memory) but you won't get the false positives.

For the lazy:

https://bitcointalk.org/index.php?topic=1306983.240
scroll down a bit where a guy says he did the transaction, and they were right no point it going all the way to 256 so he is going to shift it
to 2^160 and up the amounts in the remaining ones. - So A) if the guy is cool with it.. why do you have to think it is something nefarious?
B) if the guy moved it (and yes it was moved like he said.. you can look and see in the blockchain. C) umm the obvious one.. anyone able to move it like that could remove it.. which means he WANTS it this way... no not technically a "puzzle", but the addresses we are working on the guy could take it all out if he wanted to... the original poster is not the guy who made the transaction but the creator is cool with this .... can we move on now?

scroll back a bit and you can get most of them.. I think page 24? then move forward from there and you should have them all soon enough.. once you get used to skimming for the way they are posting the private keys you can do it in short order.

If you don't mind, I'm going to totally steal that and use it in conversation -  lucky²⁵⁶
I'm still snickering over that.

look around, and perhaps read through earlier portions of the thread, the creator of the puzzle did in fact come out and specified the why, and how of it (explaining about the 2^increasing) in fact when it was pointed out to him about anything beyond 2^160 was pointless he then moved the btc from those higher addresses into the remaining lower ones. The important point here is that A) this person MUST be the creator of the puzzle since how else could he have moved the btc? B) He WANTS people to find it.. else it would be removed. - The reasoning if I remember correctly was more mostly about  encouraging people to delve into the crypto part of it all. and maybe a little bit of "let's just see."
Use a search your engines luke.. the google flows strong within you.. use the google (or you know.. something like that.)

in hex 10 = 16 8=8 - if it will make you feel better you could do 0800000000000000- 0FFFFFFFFFFFFFFF which would be 1 shy of the whole range and I can pretty much guarantee it would not be in that last one. (I have pretty good odds there eh? hehe)

(DEC) 576460752303423488-1152921504606846976

Would probably join the pool if cpu's are okay - no nifty vid cards but a pile of old comps just sitting around, pi's etc..  but avoided it because i don't feel like downloading one more program to like telegram. partly just ugh, at the thought, partly too many other things going on.