There have been suggestions that various bitcoin protocol rules (max block size, mining reward policy, etc) could be changed in the future by everybody "agreeing to update their client". The logistics of this are somewhat questionable.

Another question asked about the mechanics of such a change in the situation where people object to it.

I would like to know if there is any recent precedent for this that we could examine. Specifically: have there ever been any changes to the official client version Y that would cause client version X to reject its blocks, where X < Y? If so, what is the most recent such case?

I suspect there were probably a bunch of changes like this back in the early days when only a few dozen people were using bitcoin. It would be interesting to know if it's happened more recently.

  • 1
    Good question--there are many such changes, and much more recently than you might think. Hopefully we can get one of the active devs to enumerate some of them? Sep 30, 2011 at 20:30

2 Answers 2


The last changes I'm aware of that would cause a blockchain split were in August 2010, after the overflow bug; see, for example, https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82

I don't think there have been any changes to the block or transaction validity rules since, although it is very possible I'm forgetting something.

  • 1
    One can argue whether it 'broke' block validity or fixed it. The client didn't do what the protocol said it should do and the change was to make it do so. It did result in clients disagreeing over whether blocks are valid, which is how I would interpret the question. Oct 1, 2011 at 0:40
  • In 0.3.12 blocks with more than a certain number of sigOps were made invalid.
    – theymos
    Oct 1, 2011 at 20:15
  • @David, sorry, I should have picked a word with more neutral connotations than "broke". I wasn't asking for a value judgment, just wondering about any sort of compatibility failure. Also, AFAIK there is no official protocol spec other than the source code for the official client. Oct 1, 2011 at 21:49

I guess I misread the question there--Gavin is right that the overflow bug of August 2010 is the only time the block chain has been affected. But in regards to the question of precedent for everybody agreeing to update their client, we do have some pretty good examples that are worth mentioning.

Take the situation with transaction fees, for example. Up until a few months ago, the Bitcoin client contained a .01 btc minimum transaction fee. In the early days this was nearly negligible, but as the exchange rate rose it started to be a pretty hefty chunk of change, especially since it was required on any transaction of less than .01 btc. Miners were allowed to include any transactions they wanted in their own blocks (and some did) but since the majority of the network would not forward transactions with insufficient fees (and the default client wouldn't even allow you to send the transaction) it was impractical for normal users to do this.

But you couldn't simply release a new client with lower minimum fees, because the transactions it produced wouldn't be forwarded by the rest of the network. This was a very similar chicken-and-egg problem to what you mention in your first paragraph. So instead of just abruptly changing the rules, an intermediate release was first made that would forward the lower-fee transactions, but not create them. Once that release obtained sufficiently wide adoption that these transactions could be used normally, a second release added the ability to actually send the transactions, and everything worked like clockwork. The same one-two model of compatibility-breaking releases could be used for virtually any needed change to the client: first release a version that supports the change passively, and wait to see if it achieves sufficient adoption. If it does, release the version that makes the change live.

For emergency situations, however, the overflow bug of August 2010 is an excellent model. An exploit was found that allowed someone to insert a fraudulent transaction into the block chain itself, so obviously any future versions had to disregard that version of events. The previous versions, meanwhile, would (accurately) view this disregarding as an attempt to fork the block chain. You can view a more detailed overview of that incident here. The exploit was noticed almost immediately, publicised, and a fix was written within hours. The vast majority of users updated their clients very quickly(especially the miners, vital to making the new fork succeed), and the new block chain fork quickly surpassed the old--bringing all the valid transactions from before with it. And disaster was averted in clockwork fashion (there were a lot more than just a few dozen people using Bitcoin by this point).

So we end up with some pretty clear precedents for both malicious action that requires an immediate response; and adjustments to the quality and usability of the network that require consensus. I'd say the idea that people can simply agree to update their client if a change is needed has a pretty firm footing.

  • Can you elaborate more on what happens if before the exploit was noticed and fixed, someone has already "did the exploit"?
    – Pacerier
    Jun 15, 2012 at 19:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.