To strengthen the MAD and prepare, I encourage people to be as ready and threatening as possible in case an immediate PoW change becomes necessary: for example, I've said several times (and I mean it) that if the Bitcoin Core devs fail to respond adequately to a miner attack, I'll propagate the necessary hardfork myself. But I oppose a preemptive PoW change unless there's some sort of new long-term solution.
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.
1. Increase maximum block size weight to the point where Chinese pool's connection can't keep up, but this is difficult since block propagation already use Compact Block
This runs both ways though. With the majority hashrate presumably being located in China it may very well be that using increased block weight as a weapon would merely lead to an increased orphan rate in Europe and the Americas, further strengthening China's position.
I think that won't happen since IMO Chinese miners would rather connect to pool outside China rather than let block orphan happen which could hurt many pools and potential FUD/price crash due to high block orphan.
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.
ProgPoW already exist (
https://github.com/ifdefelse/ProgPOW) and looks like developed well from commit/contributor number, but the hardest part is making sure existing miners won't do anything crazy such as boycott or attack network knowing MAD situation.