Looking at Bitcoin's current hashrate distribution per pool, the proportions don't seem to have shifted much [1]. Distributed evenly, a 35% hashrate increase merely means that attacking the network via hashing power just got harder.
[1]
https://www.blockchain.com/en/pools?timespan=24hoursWould be good to see how that pie chart changed before the rise and after (August 25 and August 27)
I know too little about sidechains to give an educated opinion, but what brings you to the conclusion that merge mining helps decentralization? I'm only thinking of Namecoin right now, so I might have missed some recent development in this area.
Merge mining is more useful for altcoins to prevent wild swings in hashrate and to increase the hashrate, which is necessary for security. Actually, it is the
honest hashrate that you want to maximize. Honest meaning, a hashrate provided by miners that don't attack. The main attack to worry about is double spending, but also censorship of transactions is an attack a miner can carry out.
The expected value of the honest hashrate is
h * P, where h is the hashrate and P is the probability that any given miner is honest. For native mining (no merge mining), it would make sense that P is greater (the miner is more dependent exclusively on the coin), but if the coin has low value, h will be very small, so not worth it even if P is 1. Also the variance of h and P is probably larger with native mining. For Bitcoin h is large, so it doesn't matter so much if you do merge mining, and h * P may even be greater for native mining because of a larger P. But this can change, and anyway, merge miners still have some degree of loyalty to a coin they are merge mining together with another, and as long as Bitcoin has the dominant market value, the miner is still very dependent on it. The P can also depend on what kind of "rival" coins are out there, as rival miners would just want to damage coin in order to boost another coin.
Sidechains can help by providing other blockchains where miners get paid in Bitcoin, and I think better to not allow merge mining of sidechains simultaneously, only merge mine random other coins, but all Bitcoin sidechains should be independently mined (as well as their sub sidechains), so then you get a whole tree structure of side chains, and no miner can control all chains simultaneously, since they are not merge mineable. Sidechains still needs more work in zero knowledge proofs in order to be a trustless system. The best we can do now is lock coins in a multisig address when sending to a sidechain.
Multi-algo proof of work systems can also help to decentralize mining. If you let miners choose 1 of n algos for mining, then miners will likely want to specialize in one algo, instead of try to be a "jack of all trades", so it will be hard for one miner to attack all algos and thus the chain. Though one thing I like about SHA256 is that it is really simple, so someone can easily build an ASIC at home, or a small company can build it instead of rely on centralized manufacturers. So maybe multi algo with simple algos, not those complex algos designed to prevent ASIC mining, because for those it will be easier to be a "jack of all trades" mining everything with general purpose GPUs.
In theory, yes. In practice I think this is much harder to achieve in a robust, nearly side-effect free way than one may imagine. Prime example is the mess that was BCH's EDA. That is not to say that solving this problem is impossible. I just think that it's a harder problem than it looks -- moreso with a crypto the scale of Bitcoin.
I think the 2 week block retarget with 4 times max increase/decrease is fine as it helps to prevent sybil attacks, but who knows, a more dynamic algorithm could work also.
As for my proposal to let users create "smart contracts" with miners dependent on hashrate, I think it would be easy to do because as with SegWit, there is an "anyone-can-spend" output that can be used to put extra fees that are dependent on hashrate conditions. The miner would have to add one anyone-can-spend output in his coinbase transaction that stores the reserves. There can be various contracts, but I think the standard contract should work like this: If hashrate keeps rising, then miners keep getting more rewards from those reserved fees, if hashrate drops, then the users who created those smart contracts would start getting their fees back.
The change would require new OP codes added the the script system that check for hashrate and peak hashrate. That wouldn't add much CPU time and we can add a limit of 4 years for the lookback period for the peak hashrate (anyway it would be cached in the blockindex / memory). The feature would be completely voluntary for both users and miners. I think with a chance of users getting some of their fees back, that would incentivize users to create such smart contracts with a larger fee than usual and miners would find them attractive since they can now can get more than usual amount of fees. The only issue is the UTXOs extra transactions needed (possibly increasing costs for users/miners). We want to make sure the UTXO database doesn't grow unnecessarily and any extra transactions don't waste block space. When miners get paid for the rising hashrate, they will need to make a transaction that spends some amount from each of the anyone-can-spend outputs that are still part of the reserve fees. Eventually, each of those outputs will get destroyed (multiple outputs converging to one), so I think a rising hashrate is good for destroying the extra UTXOs, and only 1 extra transaction is needed per block. The size of the transaction can be reduced by limiting the time window for such a smart contract to finish (would take a long time to dissolve the reserve if hashrate is only slightly increasing/decreasing). In the case of a falling hashrate, the anyone-can-spend outputs will split into many outputs (users getting their money back) for each block that is relevant, and that would require more block space than with miners getting paid, so maybe pay users only once the reserve is finished (i.e. contract is over), and make sure the time window for the contract is limited (like 2016 blocks for example). If the contract ends before the reserve is finished, the remaining reserve can be split evenly between miners and users, or some other specified rule.
