If I would be the creator I would laugh so hard about some of the things discussed here.
Guys, a logarithm is an abstract concept, not some math function.
You get a thing called a "base change". In this case we're dealing with a change of base of an element from some position in a finite field (private keys) to an element in the same position in a finite group (EC public keys) and the problem is to solve for the position without a way to go back from the latter to the first (which is assumed to be hard, but not yet proven). And this in the best case that we even have such an element, and not some fingerprint of it (an address), which makes the problem levels of more absurdly difficult. WTF is with the real numbers field log2 discussion, it makes no sense, we already know the ranges double in size at each step, of course any polynomial regression or whatever is a straight line. Dividing 1 by (2**64) is four levels of magnitude below a double-precision IEEE floating point, so what errors do you expect, they will always be after the 64-th zero decimal digit in reality. Nevermind the fact that there's an infinity of real numbers between any two real numbers, so an infinity of computations. Take 7 as a private key and try to solve back from [1/4, 1/8) interval, mission impossible.
This is not an analytical problem, it's a group theory problem.
Funnier than that is the circles of apocalypse 
I agree with you. It's so many problems, I will humongous lists if I start go in depth.
My idea is to see if the pseudo-randomicity of the numbers gave some clues, like I did as a work 10 years ago.
Its the only route I'm thinking tbh bc I have a old laptop and find a job is horrible rn.
But even than that, my jupyter is killing my patience and floating number problem is a REAL pain in the a**.
as a side note: I was also telling my date I was reviewing GF(n) to solve a puzzle and I confronted a quite skeptical reaction like "you are not a procrastinator person to do this as a hobby".... oh well
