Bitcoin Forum
November 29, 2020, 08:26:36 PM *
News: Bitcointalk Community Awards
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: The “26 blocks fork” in April 2013  (Read 252 times)
Betwrong
Legendary
*
Online Online

Activity: 2030
Merit: 1178



View Profile
March 30, 2018, 04:22:31 PM
Merited by achow101 (2), ETFbitcoin (1), TheQuin (1)
 #1

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!

███████████████████████████
█████████▀▄▄▄▄▄██▀▀████████
█████▀▄█▀▀▄▄▄▄▄▄▄▀▀▄▄▀█████
████ █▀▄███████████▄▀██████
███▄█ ███████▀ ██████ █ ███
██▀█ ███  ▀▀█  ▀██████ █ ██
██ █ ████▄▄      ▀▀▀██ █ ██
██ █ █████▌        ▄██ ████
███▄█ █████▄▄   ▄▄███ █▀███
████▀█▄▀█████▌  ▀██▀▄█ ████
█████▄▀▀▄▄▀▀▀▀   ▄▄█▀▄█████
████████▄██▀▀▀▀▀▀██████████
███████████████████████████

        ▄     ▀
         █ ▄▀
   ▄▀     █    ▄▀
  ▄   ▄▄  ██▄▄▀
 ▀      ▀▄▄██   ▄ ▄▄▀▀

          ▀██ ▄▀▀▀▄ ▀▄
           ███▀
 ▀▄
  ▄  ▀▄ ██▌  ▀▄
    ▀  ▄  ▐██
    ▄
   ▐██      ▄
     ▀
   ▄███▌ ▄▄   ▀
  ▄▄
▄▄ ▄█████▄ ▄▄ ▄▄
★ ‎‎
‎ ★
UP
TO
15%...CASH BACK
EVERY SPIN

‎ ★
       ▄▄██████▄▄▄
      ██▄▄▀▀█▀▀
     ████▄▀▀▄██▀
     ▄▀▀▄▄▄██▀
    ▀  ▀▀▀▀▀
             ▄▄▄▄▄▄▄
          ▄███▄▄▄████▄  ▄▄▀
        ▄████████▀▀▀█▄▀▀
     ▄███▀▀▄▄██▄▄▀▀█████
 ▄▄████▄▄▄▄▄▄▀▀████████
▀▀██▀▀▀▄▀███████▄▀████
   ▀▀██████████████▀
       ▀▀▀███████▀▀
.
..PLAY NOW..
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
ETFbitcoin
Legendary
*
Offline Offline

Activity: 1694
Merit: 2594


NotYourKeys.org - Not Your Keys, Not Your Bitcoin


View Profile
March 30, 2018, 05:56:31 PM
 #2

AFAIK, if there are nodes/miners who use different consensus/protocol rules, then it's considered as fork (aka chain-split) and it doesn't matter whether these nodes/miners can make new block or not (if they can't make new block, people just consider it's failure fork/chain-split attempt).
In this case, the different consensus/protocol rules is maximum transaction in a block which caused by Berkeley DB.

achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 2324
Merit: 3552


Just writing some code


View Profile WWW
March 30, 2018, 09:08:27 PM
Merited by Foxpup (3), Betwrong (2), ETFbitcoin (2), LoyceV (1), Taras (1), mattcode (1)
 #3

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
Legendary
*
Online Online

Activity: 2030
Merit: 1178



View Profile
March 31, 2018, 01:42:37 PM
 #4

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:

Quote
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.

███████████████████████████
█████████▀▄▄▄▄▄██▀▀████████
█████▀▄█▀▀▄▄▄▄▄▄▄▀▀▄▄▀█████
████ █▀▄███████████▄▀██████
███▄█ ███████▀ ██████ █ ███
██▀█ ███  ▀▀█  ▀██████ █ ██
██ █ ████▄▄      ▀▀▀██ █ ██
██ █ █████▌        ▄██ ████
███▄█ █████▄▄   ▄▄███ █▀███
████▀█▄▀█████▌  ▀██▀▄█ ████
█████▄▀▀▄▄▀▀▀▀   ▄▄█▀▄█████
████████▄██▀▀▀▀▀▀██████████
███████████████████████████

        ▄     ▀
         █ ▄▀
   ▄▀     █    ▄▀
  ▄   ▄▄  ██▄▄▀
 ▀      ▀▄▄██   ▄ ▄▄▀▀

          ▀██ ▄▀▀▀▄ ▀▄
           ███▀
 ▀▄
  ▄  ▀▄ ██▌  ▀▄
    ▀  ▄  ▐██
    ▄
   ▐██      ▄
     ▀
   ▄███▌ ▄▄   ▀
  ▄▄
▄▄ ▄█████▄ ▄▄ ▄▄
★ ‎‎
‎ ★
UP
TO
15%...CASH BACK
EVERY SPIN

‎ ★
       ▄▄██████▄▄▄
      ██▄▄▀▀█▀▀
     ████▄▀▀▄██▀
     ▄▀▀▄▄▄██▀
    ▀  ▀▀▀▀▀
             ▄▄▄▄▄▄▄
          ▄███▄▄▄████▄  ▄▄▀
        ▄████████▀▀▀█▄▀▀
     ▄███▀▀▄▄██▄▄▀▀█████
 ▄▄████▄▄▄▄▄▄▀▀████████
▀▀██▀▀▀▄▀███████▄▀████
   ▀▀██████████████▀
       ▀▀▀███████▀▀
.
..PLAY NOW..
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 2324
Merit: 3552


Just writing some code


View Profile WWW
March 31, 2018, 03:43:04 PM
Merited by Betwrong (2), ETFbitcoin (1)
 #5

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:

Quote
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
Legendary
*
Online Online

Activity: 2030
Merit: 1178



View Profile
April 02, 2018, 11:50:23 AM
 #6

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:

Quote
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.


███████████████████████████
█████████▀▄▄▄▄▄██▀▀████████
█████▀▄█▀▀▄▄▄▄▄▄▄▀▀▄▄▀█████
████ █▀▄███████████▄▀██████
███▄█ ███████▀ ██████ █ ███
██▀█ ███  ▀▀█  ▀██████ █ ██
██ █ ████▄▄      ▀▀▀██ █ ██
██ █ █████▌        ▄██ ████
███▄█ █████▄▄   ▄▄███ █▀███
████▀█▄▀█████▌  ▀██▀▄█ ████
█████▄▀▀▄▄▀▀▀▀   ▄▄█▀▄█████
████████▄██▀▀▀▀▀▀██████████
███████████████████████████

        ▄     ▀
         █ ▄▀
   ▄▀     █    ▄▀
  ▄   ▄▄  ██▄▄▀
 ▀      ▀▄▄██   ▄ ▄▄▀▀

          ▀██ ▄▀▀▀▄ ▀▄
           ███▀
 ▀▄
  ▄  ▀▄ ██▌  ▀▄
    ▀  ▄  ▐██
    ▄
   ▐██      ▄
     ▀
   ▄███▌ ▄▄   ▀
  ▄▄
▄▄ ▄█████▄ ▄▄ ▄▄
★ ‎‎
‎ ★
UP
TO
15%...CASH BACK
EVERY SPIN

‎ ★
       ▄▄██████▄▄▄
      ██▄▄▀▀█▀▀
     ████▄▀▀▄██▀
     ▄▀▀▄▄▄██▀
    ▀  ▀▀▀▀▀
             ▄▄▄▄▄▄▄
          ▄███▄▄▄████▄  ▄▄▀
        ▄████████▀▀▀█▄▀▀
     ▄███▀▀▄▄██▄▄▀▀█████
 ▄▄████▄▄▄▄▄▄▀▀████████
▀▀██▀▀▀▄▀███████▄▀████
   ▀▀██████████████▀
       ▀▀▀███████▀▀
.
..PLAY NOW..
cr1776
Legendary
*
Offline Offline

Activity: 2800
Merit: 1131


View Profile
April 03, 2018, 06:09:16 PM
 #7

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:

Quote
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

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!