I believe the problems with limiting (automatic) rollback to 120 blocks is smaller than the possible problem with a government building a lot of ASICs, making blocks in the dark and release them to the network after a long time. This could kill Bitcoin.
Say you limit rollback. Say about half the network watched chain X unfold and it's the longest chain. And say half the network is on chain Y and would need a rollback past the limit to get to chain X. Isn't it true that both chains are now equally correct by the rules? I'm not so sure it's such a good idea to introduce path dependence to a network that can't even remotely guarantee that all nodes take the same path.I agree, if you ever need a rollback passed a sensible limit, you're kind of screwed. But it seems to me that you're screwed whether or not you limit the rollback. You can now have two perfectly functioning clients with the same information who disagree on the which set of blocks is valid.
I would say it makes sense to detect that a very large rollback would normally occur. But as for what you do in that case, I can't see not rolling back as being right. Perhaps prevent further operation until humans can decide what to do.
So let's find the sensible limit and use that. If we set the limit at 288 blocks, we would have about 96 hours to merge the network again if there was a 50 / 50 split. I don't think we ever will have a network split larger than 96 hours with exactly 50 / 50 share on both sides. If the network merged again after 96 hours, and one side have made more blocks than the other side, miners would jump to the largest blockchain and the small one will die.
If they manually need to jump to the longest chain, if it's more than x number of blocks to roll back, we are much better protected against a hostile attack.
