Is there any agreement on how such a PoW change would be implemented and what code of conduct would be followed? For example how a new PoW scheme would be selected. I presume some thoughts has already been put into it, beyond merely considering the option.
How about start by prepare guide/reference client in-case hard-fork is needed? Reflecting from Bitcoin-Qt 0.8.0 accident (which is accidental hard-fork due to different DB version), that would help community/developer where to start solve the problem.
It's not good to have an exact algorithm planned out, since then someone could make an ASIC for it in advance.
Current consensus seems to be that in case of a miner attack, something based on SHA-3 would be used, since it's very similar to SHA-2 and therefore a minimally-significant change. There's an old
sample pull request. It should be modified slightly at the last minute to ensure that there are no stockpiled ASICs for it, though; for example:
fn newPoW(in) {
RANDOM_SALT[10] = [randomString1, randomString2, ..., randomString10]
out = in
for i in 0..9:
out = sha3(concat(out, RANDOM_SALT[0:i]))
return out
}
That's just an example of how you'd try to do something a bit different to ensure that nobody has any stockpiled, maybe-somewhat-configurable ASICs hidden up their sleeves.
It'd be nice if there was a defined procedure for selecting one quickly. The exact algorithm isn't that important as long as nobody knows it in advance and it keeps the necessary properties for a PoW, but you don't want to waste time arguing about it. Maybe you'd have the interested devs write down their suggested algorithms, confirm that they all look reasonable, select two using verifiable randomness, compose or mash-up the two selected, and then fill in any random constants in the algorithm with new verifiable randomness.
Some have proposed automatically generating new PoWs, but then it's still possible to design ASICs which can adapt to the general random scheme. For example, you could have the PoW be
sha3(concat(random_salt, sha3(in)) where
random_salt automatically updates every year or whatever based on the hash of a block 1000 blocks deep, but then people would just design an ASIC which can accept a configurable
random_salt.
Preparedness could be a lot better. I especially advocate for the creation of a clear set of criteria which indicate miner abuse so that they don't get away with something very incremental like freezing "obviously stolen" coins.
I have this idea for a long time, a 2-way concurrent PoW algorithm with a 2-3 years smooth migration from ASICs to the alternate cpu/gpu PoW method e.g. ProgPoW. I'm thinking of starting with a 10:1 ratio in favor of sha2 ASICs and a gradual transition to 1:10 ratio against them.
I've heard that before, maybe on the mailing list. Not a bad idea IMO. IIRC it can also be done as a softfork if miners are cooperative.