I'm actually quite excited about this idea. It has a sort of inevitable feel to it.
Yes. Since anyone can run any software they want to interact with the Bitcoin network, this idea does seem like a logical development.
It also seems like one of those counter-intuitive anti-fragility things, where the seeming chaos and instability at a micro level will actually lead to a more predictable and stable behaviour at the macro level.
If it became more common for individual nodes to be able to tweak consensus parameters, then I think that would actually lead to more predictable and stable consensus behaviour in the long run. The worst thing that can happen to a node operator is to fall out of consensus with the rest of the network, so individual node operators would be strongly incentivised to develop methods to ensure they can track the status of the network, and deal with any potential consensus forks.
As it stands now, consensus behaviour is based on the specific implementation details of Bitcoin Core. The software is not designed with the assumption that hard consensus forks are a likely event, and when they do happen nodes are not designed to handle it gracefully. The accidental hard form of March 2013 happened because of an obscure implementation detail in the Core software, and was only possible because the software monoculture created a "single point of failure". A more diverse implementation of consensus rules might result in more frequent consensus divergences and orphaned blocks, but each one would be non-catastrophic, and would lead toward a more stable and resilient network in the long run.
Great insight!
You bring up an interesting point: rather than viewing forks as something that must be avoided, let's view them as something inevitable and necessary for the evolution of Bitcoin, and then work to find ways to make convergence of consensus in the presence of forks as robust as possible.
I think you're right that this "seeming chaos and instability at a micro level will actually lead to a more predictable and stable behaviour at the macro level."
ZB had brought up this point before and while it does sort of makes sense from an "antifragile" standpoint, I have a problem accepting it as a viable or desirable outcome.
On that point I believe this post from Alex Morcos is relevant:
What gives Bitcoin value aren't its technical merits but the fact that people believe in it. The biggest risk here isn't that 20MB blocks will
be bad or that 1MB blocks will be bad, but that by forcing a hard fork that isn't nearly universally agreed upon, we will be damaging that belief. If I strongly believed some hard fork would be better for Bitcoin, say permanent inflation of 1% a year to fund mining, and I managed to convince 80% of users, miners, businesses and developers to go along with me, I would still vote against doing it. Because that's not nearly universal agreement, and it changes what people chose to believe in without their consent. Forks should be hard, very hard. And both sides should recognize that belief in the value of Bitcoin might be a fragile thing.
http://sourceforge.net/p/bitcoin/mailman/message/34092527/While I do understand your point about improving on the ability of the users to come to consensus, it seems a stretch to me to suggest that regular changes to the way Bitcoin operate can strengthen the trust people have in it. Rather we should strive to come to a point where the consensus critical code in Bitcoin is set in stone for eternity as it becomes harder and harder for an ever-growing ecosystem to come to consensus on a proposed change.
For that reason, I am wary and quite frankly curious of recent attempts by Hearn in particular to lessen the impact and the dangers of hard forks.