The “26 blocks fork” in April 2013

[Betwrong]

While watching Bitcoin related videos I came across this part where Andreas M. Antonopoulos is talking about an incident which occurred in April 2013 after approximately 50% of miners had started using  Google's Level DB instead of Berkeley DB. It starts here:
https://www.youtube.com/watch?v=fw3WkySh_Ho&feature=youtu.be&t=3286

As far as I understood those who were running Berkeley DB could not move to the next block while those running Google's Level DB were able to create 26 blocks.
 
My question is Why do we call it a fork given that one part wasn't able to build new blocks? I thought when we say “An X-blocks fork has happened” we mean that both parties were able to create X blocks on top of the block after which it happened.

I’m no expert in the field, so please forgive me if my question is stupid. I'm just trying to learn about Bitcoin as much as I can.

Thanks in advance for your help!

[achow101]

My question is Why do we call it a fork given that one part wasn't able to build new blocks?

They were able to build new blocks, and new blocks were in fact being built on both sides of the fork.

What happened was that miners who were using Bitcoin 0.8 had the majority of the hash rate, so they were finding blocks that were invalid to 0.7 nodes. IIRC miners still use 0.7 nodes were able to find blocks, just much more slowly. Then once the fork was known to have happened, the Bitcoin 0.8 miners downgraded to 0.7 and resumed mining on the 0.7 fork of the blockchain. Once that fork over took the 0.8 branch, all nodes once again began using the same blockchain as the chain valid to 0.7 was valid to 0.8 and had more cumulative work.

I suggest you read the post-morten BIP, BIP 50

[Betwrong]

My question is Why do we call it a fork given that one part wasn't able to build new blocks?

They were able to build new blocks, and new blocks were in fact being built on both sides of the fork.

What happened was that miners who were using Bitcoin 0.8 had the majority of the hash rate, so they were finding blocks that were invalid to 0.7 nodes. IIRC miners still use 0.7 nodes were able to find blocks, just much more slowly. Then once the fork was known to have happened, the Bitcoin 0.8 miners downgraded to 0.7 and resumed mining on the 0.7 fork of the blockchain. Once that fork over took the 0.8 branch, all nodes once again began using the same blockchain as the chain valid to 0.7 was valid to 0.8 and had more cumulative work.

I suggest you read the post-morten BIP, BIP 50

Thank you for taking time to explain this. I wasn't aware of the fact that new blocks were being built on both sides of the fork. But to tell the truth I still don't know how to interpret the words of Andreas Antonopoulos whom I respect very much and think that his videos are among the very best Bitcoin related ones:

They [the nodes running Berkeley DB] would start processing the transactions to validate them, they would open file descriptors, they would process the first 1024 transactions. And then they would attempt to validate transaction 1025, choke on it, crash, and restart. They would restart, join the network, ask it what the latest block is, receive the exact same block, start validating 1025 transactions later, choke, crash, reboot, ask for a block, validated, choke, crash, reboot. Problem is half the network adapted to Level DB, half the network was on Berkeley DB. The network suffered a complete bifurcation almost perfectly 50-50% balanced, and one side could not move forward. They couldn't move to the next block because every time they got on the network they would try to validate the same block.

I thought that meant that the nodes running Berkeley DB could not create new blocks.

[achow101]

Thank you for taking time to explain this. I wasn't aware of the fact that new blocks were being built on both sides of the fork. But to tell the truth I still don't know how to interpret the words of Andreas Antonopoulos whom I respect very much and think that his videos are among the very best Bitcoin related ones:

They [the nodes running Berkeley DB] would start processing the transactions to validate them, they would open file descriptors, they would process the first 1024 transactions. And then they would attempt to validate transaction 1025, choke on it, crash, and restart. They would restart, join the network, ask it what the latest block is, receive the exact same block, start validating 1025 transactions later, choke, crash, reboot, ask for a block, validated, choke, crash, reboot. Problem is half the network adapted to Level DB, half the network was on Berkeley DB. The network suffered a complete bifurcation almost perfectly 50-50% balanced, and one side could not move forward. They couldn't move to the next block because every time they got on the network they would try to validate the same block.

I thought that meant that the nodes running Berkeley DB could not create new blocks.

I don't think any Bitcoin 0.7 nodes were actually crashing. They were simply unable to validate the larger blocks created by 0.8. None of the threads from that time indicate any sort of software crashing.

For reference, see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-March/002235.html, https://bitcointalk.org/index.php?topic=152030.0. Here's also writeup explaining the events of the fork and the actions that were done: https://freedom-to-tinker.com/2015/07/28/analyzing-the-2013-bitcoin-fork-centralized-decision-making-saved-the-day/

[Betwrong]

Thank you for taking time to explain this. I wasn't aware of the fact that new blocks were being built on both sides of the fork. But to tell the truth I still don't know how to interpret the words of Andreas Antonopoulos whom I respect very much and think that his videos are among the very best Bitcoin related ones:

They [the nodes running Berkeley DB] would start processing the transactions to validate them, they would open file descriptors, they would process the first 1024 transactions. And then they would attempt to validate transaction 1025, choke on it, crash, and restart. They would restart, join the network, ask it what the latest block is, receive the exact same block, start validating 1025 transactions later, choke, crash, reboot, ask for a block, validated, choke, crash, reboot. Problem is half the network adapted to Level DB, half the network was on Berkeley DB. The network suffered a complete bifurcation almost perfectly 50-50% balanced, and one side could not move forward. They couldn't move to the next block because every time they got on the network they would try to validate the same block.

I thought that meant that the nodes running Berkeley DB could not create new blocks.

I don't think any Bitcoin 0.7 nodes were actually crashing. They were simply unable to validate the larger blocks created by 0.8. None of the threads from that time indicate any sort of software crashing.

For reference, see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-March/002235.html, https://bitcointalk.org/index.php?topic=152030.0. Here's also writeup explaining the events of the fork and the actions that were done: https://freedom-to-tinker.com/2015/07/28/analyzing-the-2013-bitcoin-fork-centralized-decision-making-saved-the-day/

Thanks for your further explanation! It was interesting to know that even in Bitcoin the human element becomes crucial sometimes. So I guess it would be right to say that having a great team of developers is essential for any cryptocurrency. However good it was designed it may encounter encounter such issues when prompt measures by the team are required.

[cr1776]

Thank you for taking time to explain this. I wasn't aware of the fact that new blocks were being built on both sides of the fork. But to tell the truth I still don't know how to interpret the words of Andreas Antonopoulos whom I respect very much and think that his videos are among the very best Bitcoin related ones:

They [the nodes running Berkeley DB] would start processing the transactions to validate them, they would open file descriptors, they would process the first 1024 transactions. And then they would attempt to validate transaction 1025, choke on it, crash, and restart. They would restart, join the network, ask it what the latest block is, receive the exact same block, start validating 1025 transactions later, choke, crash, reboot, ask for a block, validated, choke, crash, reboot. Problem is half the network adapted to Level DB, half the network was on Berkeley DB. The network suffered a complete bifurcation almost perfectly 50-50% balanced, and one side could not move forward. They couldn't move to the next block because every time they got on the network they would try to validate the same block.

I thought that meant that the nodes running Berkeley DB could not create new blocks.

I don't think any Bitcoin 0.7 nodes were actually crashing. They were simply unable to validate the larger blocks created by 0.8. None of the threads from that time indicate any sort of software crashing.

For reference, see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-March/002235.html, https://bitcointalk.org/index.php?topic=152030.0. Here's also writeup explaining the events of the fork and the actions that were done: https://freedom-to-tinker.com/2015/07/28/analyzing-the-2013-bitcoin-fork-centralized-decision-making-saved-the-day/

Yeah, neither of the 2 pre-0.8 nodes I was running crashed at the time (and one was quite old).  For all intents and purposes it was over practically before most people even were aware it had occurred because (a) it took a little while to notice, (b) it wasn't that long, and (c) many people weren't online right at that moment.


There is some more information here:
https://bitcointalk.org/index.php?topic=152282.0;all
http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/03/12
https://bitcointalk.org/index.php?topic=152348.0