9
2
I keep coming across answers in questions on this site and on the wiki saying that the protocol might need to be changed in the future to create more scalability / security.
It seems to me that it is difficult to update the protocol now that there are so many different people involved and so much invested in the current protocol.
How could the bitcoin protocol be updated? Has this ever occurred to date?
5
Easy. In the source code add a conditional. For example, if the protocol were needing to be changed for all verifications after block 200,000 then the pseudo code for that is:
If block <= 200,000: # Do it the old way. Else: # Do it the new way.
The problem isn't technical it is political. If that change causes me pain (e.g., inflate the currency at a higher rate) then I am not going to want to accept any version of the code that does something that I don't want to see happen.
So any change needs to get buy in (concensus), from the developers, miners and ... most importantly, those who will accept bitcoins under the new rules in exchange for something of value.
If an unwanted change is pushed forward without being widely accepted, a blockchain fork will occur, and the losing side (generally the fork with the new rules) essentially gets ignored as if it didn't even exist by the rest of the network.
There have been several changes to the protocol as well as changes to the implementation in the client. Some are planned well in advance (e.g., BIP 16), and some are in response to a problem (e.g., Aug 2010's value overflow).
2
It has been changed in the past. For example, the version message was updated. It was carried out by basically saying: "Okay, on this and this date, the protocol will be changed" and giving enough time for non-standard clients to update. Then, at a predefined time all clients updated their protocol version internally and started communicating in the normal way.
The main problem with protocol updates, is that once they are introduced, more often than not a majority of clients need to be updated before the change is scheduled, or there will be a lot of mess. This is a case for both the non-standard clients (which means their owners need to be up-to-date with the changes) and the standard client.
@Stephen, Does that mean that in the future, Bitcoin can effectively have faster than 10 minute confirmation times (like LTC/worldcoin etc)? – Pacerier – 2014-03-20T17:07:06.983
@Pacerier: Yes, if enough people are convinced. Though this is a change at the very core of Bitcoin's implementation, so it's technically challenging to get the change right, thus it will be difficult to convince to make the change. – Meni Rosenfeld – 2014-04-20T11:39:47.467
@MeniRosenfeld, why not? If there's anything wrong with bitcoin, it's that the 10 min confirmation is simply too slow isn't it? – Pacerier – 2014-04-21T14:30:06.813
@Pacerier: There are many potentially wrong things with Bitcoin. the 10-min block time may be one of them. However, the question isn't just "Is X minutes better than 10 minutes?", It's "Is making such a technically challenging change worth the risk?". Changing this for an already running chain is not like starting a whole new blockchain with a different parameter. That said I do believe eventually GHOST will be implemented and the block time be reduced substantially. – Meni Rosenfeld – 2014-04-22T12:01:55.947
So it follows that changes will likely only be implemented and adopted if it benefits a large majority of participants. I suppose most security updates would qualify. Technically, isn't it the case that we only need a majority of miners (>50%) to switch over? Or does it require more than that? – Muhd – 2012-06-13T23:28:28.420
4@Muhd: No, a majority of miners is irrelevant. If miners try to change the protocol on their own, they will simply be ignored by the rest of the network, and their "mining rewards" will be worthless. A change requires an economic majority - adoption by the users and businesses who give the currency value. – Meni Rosenfeld – 2012-06-14T13:53:19.780