<p>I don't think anyone known exactly what the problem is, yet (note to future readers: the flaw was discovered just few moments ago).</p>

<p>I found this on the #bitcoin-dev IRC channel:</p>

<blockquote>
  <p>sipa:  Diablo-D3: just saying that the breaking block had 1700
  transactions, but affected over 5000 block index entries</p>
</blockquote>

<p>It's probably is a problem with "Berkeley DB" (0.8 use LevelDB and this is <em>could</em> be why 0.8 isn't affected).</p>

<ul>
<li>Also why was the solution to push the 0.7 chain instead of 0.8?</li>
</ul>

<p>The 0.7 chain is accepted by both 0.7 and 0.8 clients/miners. The 0.8 chain is only accepted by 0.8 clients/miners. So to avoid creating a (larger) fork, most 0.8 mining pools have downgraded to 0.7</p>

CC BY-SA 3.0
2013-03-12T02:19:13.707Z
I thought the network was supposed to take care of things like this? Is it because this block was so large?
CQM
CC BY-SA 3.0
2013-03-12T02:34:19.337Z
It's crucial that the whole network follows the same rules, or else we will get forks. It this case, both 0.7 and 0.8 follows the same rules, but an underlying flaw in 0.7 means that 0.7 can't accept the 'flawed' block, so 0.7 will classify it as a invalid block. 0.8 **can** accept it, so it will accept it, and now 0.7 and 0.8 follows different rules ( = fork ).
Nicolai
CC BY-SA 3.0
2013-03-12T02:36:18.053Z
oops. so because more people use the flawed 0.7 they will go with that? I suppose this will prevent people from upgrading to newer versions
CQM
CC BY-SA 3.0
2013-03-12T02:38:49.050Z
actually 0.8 had most mining power, but because it's way smarter to get the 0.7 blockchain to become the 'master' blockchain, most mining pool prompty switched back to 0.7, so now 0.7 has the most mining power (and will soon become the 'real' blockchain). Right now 0.8 is the highest blockchain.
Nicolai
CC BY-SA 3.0
2013-03-12T03:28:11.690Z
Yeah I was a bit confused on why they didn't just leave 0.8 as the longest chain. It seems like it would have been a huge PR disaster and a bad precedence to set, but seems like the more idealistic solution.
placeybordeaux
CC BY-SA 3.0
2013-03-12T02:11:18.070Z
2013-03-12T02:11:18.070Z
Nicolai
<p>The solutions for next step might be works, ex 0.8.1, might be:</p>

<p>First limit the block size generate by miners, with the same size of 0.7's DB, other are the same with 0.8.</p>

<p>After all client are upgrade to 0.8.1, then upgrade to 0.8.2 with the feature:</p>

<p>remove the limitation of the block size 0.8.1's miner can generate, and the 0.8.1's DB can accept the larger block size, require that there is almost no 0.7 client now.</p>

<p>My opinion about the limitation is:</p>

<p><strong>The block size miners generating should separate from which clients accepts(sync).</strong></p>

<p><strong>So, The upgrade for miners should also separate from common clients.</strong></p>

CC BY-SA 3.0
2013-03-12T03:24:28.113Z
2013-03-12T04:14:28.713Z
2013-03-12T04:14:28.713Z
HackFisher
<p>Given the <a href="http://pastebin.com/sGYnpkED" rel="noreferrer">&lt;0.8 bug</a> and subsequent fork happened because of a particularly large block, does this mean that large blocks can not be used until the large majority of the community switches to 0.8?</p>

<p>Also why was the solution to push the 0.7 chain instead of 0.8?</p>

<blockchain-fork><march-2013-fork>
Given the recent <0.8 bug, when can we safely have larger block sizes?
placeybordeaux
# Given the recent <0.8 bug, when can we safely have larger block sizes?

(Asked by: username_0 on 2013-03-12)

Given the [<0.8 bug](http://pastebin.com/sGYnpkED) and subsequent fork happened because of a particularly large block, does this mean that large blocks can not be used until the large majority of the community switches to 0.8?

Also why was the solution to push the 0.7 chain instead of 0.8?

**Tags:** blockchain-fork, march-2013-fork


---

## 2 answers

### Answer by username_1 on 2013-03-12. Score: 3 | Accepted answer

I don't think anyone known exactly what the problem is, yet (note to future readers: the flaw was discovered just few moments ago).

I found this on the #bitcoin-dev IRC channel:

> sipa: Diablo-D3: just saying that the breaking block had 1700
> transactions, but affected over 5000 block index entries

It's probably is a problem with "Berkeley DB" (0.8 use LevelDB and this is *could* be why 0.8 isn't affected).

* Also why was the solution to push the 0.7 chain instead of 0.8?

The 0.7 chain is accepted by both 0.7 and 0.8 clients/miners. The 0.8 chain is only accepted by 0.8 clients/miners. So to avoid creating a (larger) fork, most 0.8 mining pools have downgraded to 0.7

> **Comments:**
> **username_2**: I thought the network was supposed to take care of things like this? Is it because this block was so large?  
> **username_1**: It's crucial that the whole network follows the same rules, or else we will get forks. It this case, both 0.7 and 0.8 follows the same rules, but an underlying flaw in 0.7 means that 0.7 can't accept the 'flawed' block, so 0.7 will classify it as a invalid block. 0.8 **can** accept it, so it will accept it, and now 0.7 and 0.8 follows different rules ( = fork ).  
> **username_2**: oops. so because more people use the flawed 0.7 they will go with that? I suppose this will prevent people from upgrading to newer versions  
> **username_1**: actually 0.8 had most mining power, but because it's way smarter to get the 0.7 blockchain to become the 'master' blockchain, most mining pool prompty switched back to 0.7, so now 0.7 has the most mining power (and will soon become the 'real' blockchain). Right now 0.8 is the highest blockchain.  
> **username_0**: Yeah I was a bit confused on why they didn't just leave 0.8 as the longest chain. It seems like it would have been a huge PR disaster and a bad precedence to set, but seems like the more idealistic solution.  

---

### Answer by username_3 on 2013-03-12. Score: 0

The solutions for next step might be works, ex 0.8.1, might be:

First limit the block size generate by miners, with the same size of 0.7's DB, other are the same with 0.8.

After all client are upgrade to 0.8.1, then upgrade to 0.8.2 with the feature:

remove the limitation of the block size 0.8.1's miner can generate, and the 0.8.1's DB can accept the larger block size, require that there is almost no 0.7 client now.

My opinion about the limitation is:

**The block size miners generating should separate from which clients accepts(sync).**

**So, The upgrade for miners should also separate from common clients.**


---

