If you think Bitcoin is going to fail, then you're better off switching to a different currency then trying to rearrange deck chairs on the Titanic.
If I were about to buy fire insurance for my new house, would you tell me "If you think that house is going to burn down, you might as well just buy a different house"? There's nothing wrong with trying to make the worst case scenario less bad just in case, if the cost of doing so is low enough.
If Classic forked and kept the hashpower lead for a month, then lost the lead and the chain was reorged back into the original chain, that wouldn't mean Bitcoin failed. Just because I think a particular fork attempt will fail with probability p, doesn't mean I think Bitcoin will fail with probability p.
Second, rational people think in terms of expected value. I might think the big block fork has a 95% chance of success, but why would I want that remaining 5% to be more disastrous than it needs to be, if I can cheaply prevent it?
I don't get why you seem to prefer an asymmetrical HF. Let's say you can wave a magic wand and generate rock solid code for either a symmetric or asymmetric fork. It sounds like you'd pick asymmetric even if the effort were identical. If so, why?
My favored methods of hardforking would be the following:
...
- Asymmetric hardfork without any significant opposition to the idea in the community
I don't get why you prefer asymmetric over symmetric in this case given the preceding discussion. Yes, if there is no opposition in the community the advantages of symmetric shouldn't matter. But you can't really know that an opposing fork won't form. Symmetric HFs should be about as easy to code up. So why not make it symmetric just in case? What downside are you seeing?
Slightly topic change: Do you think ETC had been the way it is, if the POW difficulty re-target would have been similar to the one we have in Bitcoin (2016@10mins block)?
...so, a block every 3.3 hours if hashpower is 5%? I think the ETC people probably would have HF'd to reset the difficulty in that case.
[doublepost=1469941903][/doublepost]
How does it follow that Classic gaining 51% ( a.k.a. "the lead" ) at fork time does not orphan Blockstream/Core chain when later Core temporarily gains the lead and orphans Classic - according to your opinion.
That is the nature of asymmetrical forks. The Classic coin pulling into the lead can't orphan the Core chain, because the Core nodes don't recognize the Classic blocks as valid. They still see the Core chain as the longest valid chain. The reverse isn't true. If Core ever pulls ahead, the Classic nodes will follow it and orphan the entire Classic chain starting from the fork, because Core blocks are valid according to Classic nodes.