8

Given the <0.8 bug 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?

3

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

  • I thought the network was supposed to take care of things like this? Is it because this block was so large? – CQM Mar 12 '13 at 2:19
  • 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 Mar 12 '13 at 2:34
  • 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 Mar 12 '13 at 2:36
  • 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 Mar 12 '13 at 2:38
  • 1
    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 Mar 12 '13 at 3:28
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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