First let me say that I’ve worked extensively with the algorithm, and as far as I’m concerned it is sound and meets its objective of evening the mining playing field. As proposed ProgPow creates a new pseudo random sequence of OpenCL or CUDA code every 10 blocks or so. In order to run on the GPUs this code is just-in-time recompiled at run-time with each new ProgPow period. In an ideal world that would be fine, but compilers (specially optimizing compilers) are incredibly complex beasts and are subject to undiscovered and subtle bugs.
Case in point, while working with ProgPow I stumbled on such a bug in all current AMD drivers (both Linux and Windows). Progress in resolving the issue at AMD is slow as the bug report was opened and acknowledged some 2 months ago (initially announced by ifdefelse here: https://medium.com/@ifdefelse/progpow-progress-da5bb31a651b) . In that instance the high level code was generated correctly by the miner but for some random sequences and ProgPow periods the generated GPU code was incorrectly compiled. Workarounds where found and implemented, but it got me to thinking… what if something like this had happened on the main net? All of the AMD miners (a majority of which use the driver in question) would start generating invalid solutions for all blocks within any given and unpredictable ProgPow period. Fairly catastrophic events!
Reliance on the dynamic use of 3rd party compilers is the weakest link in the ProgPow chain. OpenCL and CUDA compiler versions can change with any driver release, and ProgPow has many attributes of a compiler fuzz tester. It becomes a prime candidate for exposing these unknown compiler optimization issues. Given the pseudo random nature of the dynamically generated code, the nearly infinite variations, and the fact that it is only compiled at run time, it is nearly impossible to do any advance testing of these code sequences. I wouldn’t ignore the likelihood of such bugs cropping up unpredictably in the future.