This is to discuss the notion of an “abort switch”, which would enable a more ordered withdrawal of a planned network upgrade in installed Ethereum clients should a bug or security vulnerability require that the upgrade be delayed. In the current configuration, clients must issue an update and coordinate a software update with miners and other runners of nodes.
Regarding the upgrade switch that @karalabe brought up: I wanted to comment, but did not want to take more time on the call. I think it can be designed in a way that it does not present centralisation vector. I see it as a voting multisig with a very limited power - to skip a network upgrade. Any abuse of this power would be accountable, because we will see who pulled the trigger. Normally, the discussion and emergency call would still happen, and only after that, the key holders will “do their duty”. If someone does it before the agreement call, it is clearly seen. And, of course, the membership of the multisig is regularly reviewed, and inactive participant removed. Also, if the multisig becomes completely compromised, removal of its powers can still be done via hard-fork coordinated in the “usual” way
And, of course, it should be opt-in from the clients
I think we should not shy away from such mechanism. Informal structures that make these kind of decisions already exist, and we know that. Making them formal actually make the process MORE transparent, not less