Creating a fork is not impossible. What is likely impossible will be convincing the bitcoin community to incorporate your fork which, to me, addresses only a temporary and minor adjustment occurring at known points of time in the future.
My apologies if I was overly flip in response to your own sally. My point was just that the difficulty is not in changing the code, but just in getting adoption by the consensus of the community. I said as much in my first post, so I don't disagree. I just don't see a reason that a consensus can't be formed if the community is at all reasonable. You haven't really argued with my reasoning, you've just said that a) it may not be bad enough to merit a change, and b) it only happens once every four years. Both true, but personally, if a protocol has a systematic flaw, even if the flaw is infrequent, I'd like to correct it rather than just let it be. And I still think that it will be a really bad time for the performance of the network, if the miner supply economy is at all matured at that point. The forewarning might mean that some get out ahead of time, though I think they'll all keep mining as long as they can make the most profit, and when it becomes unprofitable, get out or scale back to the point where it does. I don't think 50% would quit, as you posited above, but I wouldn't rule out a third.
As to the fees, I'm going to pick the latest ten fees as I write this post: 0, 0.0805, 0.13455706, 0.0905, 0.1535, 0.1365, 0.05, 0.26886086, 0.0305, 0. So, the total BTC mined by these transactions is 500.944, of which 500 are subsidized Bitcoins and 0.944 (about 0.19%) is fees. So really, I think we can neglect fees at least for the near future as a factor in miner income, unless there's a reason to expect they're going to grow dramatically over the next year.
More importantly, I think you significantly overlook a little detail.
Bitcoin absolutely relies on trust. Trust that the rules (the protocol) will not be mucked with. That the protocol can survive as-is, and not require a change whenever someone comes up with suggestions for improvements or perceives it to somehow be flawed.
You seem to have an almost religious faith and conviction about the fitness of the Bitcoin protocol. Do you believe that the algorithm as it exists is really the best that could be done and is not at all in need of any improvement? It's an impressive protocol, but I doubt even the original author would make that assertion. He's not a prophet, and the code isn't written with the finger of God. There have already been technical errors found and corrected, and algorithmic flaws like this are, in my opinion, of just as high an importance.
I prefer to say Bitcoin relies on consensus. Trust implies that you believe that your own judgment is inadequate and you have to substitute that of others. Consensus means that many informed people have made their own judgments and come to an agreement. That said, there is a certain plan and expectation laid out that can be considered a form of contract with the community, but I don't think tweaks that only apply to far future operation and only aim to fix flaws coming from the ad hoc initial implementation of the protocol are terrible. At the most you could claim that reducing the subsidy incrementally as described above would decrease the terminal number of bitcoins. Personally, I don't think that's a big deal, but if so, you could implement the ramp balanced around the transition point, and that would net to exactly zero change in the total number. Likewise changes like the rebalancing to 1 or 2 minutes per block that only improve the function of the network and don't degrade it are probably acceptable, as long as nobody's making money that they wouldn't be making anyway. The only reason to reject changes that have only upside and no downside would be hidebound stubbornness as far as I can see, the same kind of dogmatic inertia that plagues the worst types of conservatives. (And I'm fairly conservative myself, for what it's worth.)
That's not to say the changes I discuss above have only upside. Part of my hope in this initial post was to gather information to try to determine whether there was a downside, and I still hope to learn more.
However, at this stage in the project, I think there is enough centralization that these minor changes, which change the "letter" of the protocol while keeping intact the spirit, could reasonably be addressed. If the main development group announced support of the changes, incorporated them into the client, and got the major exchanges and vendors on board, the community would follow. Why wouldn't they? If the changes were made around block 185000, that would be a year for the changes to propagate around the net. If it were 197500 for the balanced ramp, that would be even longer. I'd be surprised if anybody went that long without adopting new software versions. Of course, the closer in time we get, the harder it would be to push through adoption, so that's why it's a question for now and not later. Are these, or any other changes, worth fighting for? And that is the reason for this discussion.
