It's regrettable...
a desperate maneuver....
Understand this...
There's no magical difference in GPU effort between processing a large block with prefixes or stopping at 65%. The workload is the same. What changes is that you're throwing away 35% of your probability due to an arbitrary stoppage, while we're reinvesting it in mobility.
Stop sugarcoating the "Dynamic Scheduler" as something impossible or that degrades performance tenfold. @WP is already doing it. Their tests demonstrate that it's feasible and efficient. You can't argue that something "can't be done" when someone has already published the results of doing it.
The prefix method is the best strategy for "trying your luck" because the "failure" isn't a dead end at the end of each block. It's a calculated statistical failure (less than 1/N).
The last proton in existence will decay itself before the mythological unicorns you are bragging about will prefix their way into breaking three layers of cryptography and de-contaminate the location biases of the freaking data entropy-filled blocks.
Since You are obviously right, as usual, you should take on Bram's advice and publish your remarkable ideas in a serious environment, where the world's cryptographers can take note of your astonishing discoveries.
After that, you should present the implementation that breaks the laws of basic computing: running s sequential algorithm in parallel.
At last, maybe you should also present your "dynamic scheduler" that works just as fast as... not having any. Because "workloads". LMFAO is the best I can react, since it's clear you're totally clueless on why H160 even runs fast on a GPU (hint: it's because it isn't bloated with bullshit ideas).
Wow, you've turned a technical thread into a circus of nonsense, sarcasm, and things taken out of context, just because you can't accept that blind cutting is strategically absurd compared to the dynamic probability of prefixes... congratulations, you've earned the respect of the forum trolls!
