I’ve been looking for versions of secp256k1 that can run on GPUs. I’ve found this project, which seems like a fork: https://github.com/ilaychen/ECDSA-OpenCL
Maybe it would make sense to upstream some of these changes, to better support GPU acceleration? Am willing to donate 7900 XTX to Sipa.
I saw this comment: #502 (comment)
I’m not sure what that meant other than it’s possible, and GPUs certainly have improved since that paper was written 10 years ago. It might make sense to revisit this.
Thanks for the suggestion.
GPU supports sounds very interesting for speeding up verification, but I doubt that this is something we should add to our roadmap. (We don’t have a written roadmap, but if we had one, I don’t think it would be on it. The lack of responses here confirms this.) That means, feel free to work on it, and maybe then there’s a chance to get this accepted. But don’t expect us to spend time on this right now.
It might be interesting to try to outline what would be needed to make such changes upstreamable here.
I would guess that changing scalar/field datatypes wouldn’t be acceptable. Probably not changing entire algorithms … but maybe if there was like like, an entire new ecmult_multi_opencl_impl.h which normally isn’t compiled in, that could be ok? And changing the build system and adding new SECP256K1_ attributes to functions (which are suitably #ifdefed in util.h) woud probably be fine.
I think as long as it’s an additional implementation that can be turned off (we certainly want to keep targeting CPU-only users), there’s not even a fundamental reason not to change datatypes or algorithms. It’s “just” an additional burden to maintain multiple algorithms, but that’s one of many variables that would influence a decision to merge (amount of performance improvement, maintainer buy in/skills, reviewer power, …)
FWIW, here’s an ancient thread about this topic: https://bitcointalk.org/index.php?topic=3238.0