<p>I guess I misread the question there--Gavin is right that <strong>the overflow bug of August 2010 is the only time the <em>block chain</em> 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.</strong></p>

<p>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.</p>

<p>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.  <strong>This was a very similar chicken-and-egg problem to what you mention in your first paragraph</strong>.  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.  <strong>The same one-two model of compatibility-breaking releases could be used for virtually any needed change to the client</strong>:  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.</p>

<p><strong>For emergency situations, however, the overflow bug of August 2010 is an excellent model.</strong>  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 <a href="https://en.bitcoin.it/wiki/Incidents#Value_overflow">here</a>.  <strong>The exploit was noticed almost immediately, publicised, and a fix was written within hours.</strong>  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.  <strong>And disaster was averted</strong> in clockwork fashion (there were a <em>lot</em> more than just a few dozen people using Bitcoin by this point).</p>

<p>So <strong>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</strong>.  I'd say the idea that people can simply agree to update their client if a change is needed has a pretty firm footing.</p>

CC BY-SA 3.0
2012-06-15T19:24:35.313Z
Can you elaborate more on what happens if before the exploit was noticed and fixed, someone has already "did the exploit"?
Pacerier
CC BY-SA 3.0
2011-10-01T00:03:35.763Z
2011-10-01T00:03:35.763Z
eMansipater
<p>The last changes I'm aware of that would cause a blockchain split were in August 2010, after the overflow bug; see, for example, <a href="https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82" rel="nofollow">https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82</a></p>

<p>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.</p>

CC BY-SA 3.0
2011-10-01T00:40:57.480Z
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.
David Schwartz
CC BY-SA 3.0
2011-10-01T20:15:14.123Z
In 0.3.12 blocks with more than a certain number of sigOps were made invalid.
theymos
CC BY-SA 3.0
2011-10-01T21:49:33.823Z
@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.**
eldentyrell
CC BY-SA 3.0
2011-09-30T20:59:15.687Z
2011-09-30T20:59:15.687Z
gavinandresen
<p>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.</p>

<p><a href="https://bitcoin.stackexchange.com/questions/1207/what-happens-if-the-developers-make-a-controversial-change-to-the-standard-clie">Another question</a> asked about the mechanics of such a change in the situation where people object to it.</p>

<p><strong>I would like to know if there is any recent precedent for this that we could examine.</strong>  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 &lt; Y?  If so, what is the most recent such case?</p>

<p>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.</p>

CC BY-SA 3.0
2011-09-30T20:30:03.583Z
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?
eMansipater
<blockchain><protocol>
What was the most recent change to the official client that broke block validity?
eldentyrell
# What was the most recent change to the official client that broke block validity?

(Asked by: username_0 on 2011-09-30)

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](https://bitcoin.stackexchange.com/questions/1207/what-happens-if-the-developers-make-a-controversial-change-to-the-standard-clie) 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.

**Tags:** blockchain, protocol

> **Comments:**
> **username_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?  

---

## 2 answers

### Answer by username_3 on 2011-09-30. Score: 12 | Accepted answer

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.

> **Comments:**
> **username_4**: 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.  
> **username_5**: In 0.3.12 blocks with more than a certain number of sigOps were made invalid.  
> **username_0**: @username_4, 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.**  

---

### Answer by username_1 on 2011-10-01. Score: 8

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](https://en.bitcoin.it/wiki/Incidents#Value_overflow). **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.

> **Comments:**
> **username_2**: Can you elaborate more on what happens if before the exploit was noticed and fixed, someone has already "did the exploit"?  

---

