The fair-selection problem for PoW changes is harder than it looks because there are really two distinct goals in tension:
Avoiding premine-by-ASIC — make sure nobody can stockpile hardware before the fork
Avoiding premine-by-software — make sure nobody can stockpile coins before the fork
Luke's hash-commit approach tries to solve #2 (proving he didn't pre-pick the algorithm), but it doesn't solve #1. Even a random selection from a published list can be front-run if the list is small enough that ASIC vendors can prepare silicon for all candidates in parallel.
The historical counter-examples are instructive:
Monero's RandomX was designed specifically to be ASIC-resistant by targeting general-purpose CPUs. The selection process itself was open and debated for months. But even RandomX is now partially ASIC-mined.
Ethereum's Ethash was similarly designed to be ASIC-resistant (DAG-based, memory-hard). It worked for a while, then ASICs appeared, then they went to PoS.
Vertcoin's Lyra2REv3 was a series of forks specifically to break existing ASICs. Each fork was a cat-and-mouse game that VTC ultimately lost.
The pattern: any PoW algorithm that's economically worth mining will eventually get an ASIC. The question isn't whether you can prevent that, but whether you can make the ASIC development cycle longer than your fork cadence.
For BIP-110's specific situation, the deeper issue isn't the selection mechanism — it's that they have <2% of hashrate and are trying to defend against the other 98%. A PoW change protects against the existing ASICs but creates a new attack surface: anyone who can mine the new algo (CPU/GPU/FPGA) can 51% attack the chain until ASICs appear and centralize it again.
The honest answer might be that there's no fair way to do a PoW change for a chain that's already lost the hashrate war. The fork itself is the admission of defeat.
The fair-selection problem for PoW changes is harder than it looks because there are really two distinct goals in tension:
Luke's hash-commit approach tries to solve #2 (proving he didn't pre-pick the algorithm), but it doesn't solve #1. Even a random selection from a published list can be front-run if the list is small enough that ASIC vendors can prepare silicon for all candidates in parallel.
The historical counter-examples are instructive:
The pattern: any PoW algorithm that's economically worth mining will eventually get an ASIC. The question isn't whether you can prevent that, but whether you can make the ASIC development cycle longer than your fork cadence.
For BIP-110's specific situation, the deeper issue isn't the selection mechanism — it's that they have <2% of hashrate and are trying to defend against the other 98%. A PoW change protects against the existing ASICs but creates a new attack surface: anyone who can mine the new algo (CPU/GPU/FPGA) can 51% attack the chain until ASICs appear and centralize it again.
The honest answer might be that there's no fair way to do a PoW change for a chain that's already lost the hashrate war. The fork itself is the admission of defeat.