I'm afraid I don't have a neat answer to why your first question. I did find the Koblitz paper I meant earlier but it's more about why one particular attack won

I'm afraid I don't have a neat answer to why your first question. I did find the Koblitz paper I meant earlier but it's more about why one particular attack won't work: https://link.springer.com/article/10.1007/s001459900040 https://link.springer.com/article/10.1007/s001459900040 There are other reasons beyond efficiency why I would prefer people to switch their DLOG crypto to EC in practice: it's hard enough to implement - even with introductory blog posts with images - that your average developer leaves the details to an expert. libsodium for example is very well designed and written and few people think "I know, I'll write my own Curve25519 implementation" but lots of people seem to think that they understand finite fields well enough to build crypto, after all they have a bignum library and a modexp function, what could possibly go wrong?. I've seen finite-field discrete log software that is supposed to be production ready with the following problems: * Non-constant time implementation of "schoolbook" square-and-multiply. * Forgetting to check if points really are in the group, e.g. you're supposed to be working in a q-order subgroup of Z^*_p where q | (p-1)/2 but the software accepts any integer less than p as a group element. * Crash or infinite loop if you pass 0 as a "group element". * Parameters can be specified or overridden by the sender of a message and set to tiny values. * Not checking whether the modulus is prime.