You forgot to mention the even/odd inverse function. The problem is still open.
Yo, you're on the right track with that batch point addition logic from JLP, especially how you're mixing in batch processing like Cyclone does. But here’s the thing. You need a compressed database. Or, if you wanna keep it light, whip up a database that only takes up 8 bytes. Kinda like that slick public key database from @Mcdouglas-X3. That’ll speed things up big time, givin’ you enough bandwidth to hit at least 90 bits.
[/quote]
Definitely JLP has implemented the fastest logic possible.
But of course it is not his invention but many others from pro cryptography domain.
I will implement JLP way in Point_Search just for kicks. And yes using compressed database could make things better.
Hitting any higher bits with CPU code like 80..90bits depends on the size of elements used for database for sure.
Point_Search is by design not a puzzle solver. But emerged from testing even/odd concept. That is what interests me most.
I have an idea for improved BSGS with bloomfilter JLP way, but way of scanning the space a little different. Havent tested it yet.