I went into this knowing that without GPU acceleration or distributed systems, my chances of finding the key were practically zero. But for me, this was less about cracking ECC and more about learning and challenging myself.
This is only partly true. The only thing a GPU is better at in this scenario is higher electricity costs.
GPUs can do insane amount of parallel work and thats because the Pollard Kangaroo algorithm is statistically faster than BSGS on a GPU, because the nature of the algorithm relies on collision delection and random walks. However, there is no garuantee that you find said solution in sqrt(k2-k1) steps.
BSGS on the other side, receives its performance due to a big precomputed baby step table. This means for every known public key in the table, you can reduce the number of ECC operations (which are known to be slow, even when optimized).
The only constraint here is available memory so in practise this means BSGS will most likely never achieve perfect runtime simply because there is not enough memory in the world. However, if you have high CPU cores and high RAM - it most likely performs better on CPU than on GPU due to more memory available.
Even though the process didn’t lead to a solution, it gave me a deeper appreciation for the strength of ECC and how robust these systems are. (...)
I share this not to "reinvent the wheel" or to claim expertise, but because I found the process rewarding and hope others might learn from my mistakes or even just my curiosity. While I’ll be stepping away from this puzzle, I’ve gained a lot from the experience, and for me, that’s what matters most.
Well, the fact that you realized how hard it is, to crack the ECDLP, even when the problem is made much easier on purpose is valuable. That means you most likely understand now the main point of those puzzles.