Due to a difference between two versions of the Bitcoin client (running v0.7 and v0.8 respectively) a fork has occurred when v0.8 clients generated a block that v0.7 blocks could not process. As a result, the two clients diverged and generated different, separate Blockchains—the functional way that Bitcoin transactions and wallet balances are recorded and kept in sync—due to the fork, suddenly users who use the separate clients would not be able to properly interact with one another.
Right now, The Bitcoin Trader has an excellent up-to-date article on the situation and ongoing updates as it proceeds. Read below for an overview of what’s up with the fork and what to expect.
Allowing the fork to continue would cause a fundamental split between v0.7 and v0.8, generating two different pools of transactions. The event is being described as an emergency and a warning was sent via Github through Bitcoin client version 0.8.0 by Gavin Andresen, lead developer of the Bitcoin project.
Not too long ago Andresen also posted a warning, “Everybody mining on version v0.8 should stop mining for now. When you start again in a few hours, you should set your maxblocksize to 500k or less,” and a tweet directing people to the thread on bitcointalk.org detailing how to deal with the fork.
Currently, it is speculated that the fork was caused by miners using the v0.7 client rejecting a too-large block mined by the v0.8 client. An expert believes that v0.8 uses LevelDB and v0.7 uses BerkleyDB—as a result the LevelDB can accept blocks larger than the older BDB setup. A block a block exceeding a certain size at 235430 in the chain got accepted by v0.8 but not v0.7.
For a thorough explanation of why the fork happened, read what Pieter Wuille has to say,
0.7 and older nodes use BDB for storing the blockchain databases. It seems this database has a limit on the size of the modification it can make atomically to the database. With the larger blocks of the past days, it seems to have triggered the limit. The result is that 0.7 (by default, it can be tweaked manually) will not accept “too large” blocks (we don’t yet know what exactly causes it, but it is very likely caused by many transactions in the block). Specifically, block
000000000000015c50b165fcdd33556f8b44800c5298943ac70b112df480c023 (height=225430) with >1700 transactions.
However. 0.8 (which uses a different database system) has no such limit, and happily accepts the block. As the majority of the hash power was on 0.8, the longest chain ended up using this block, which is not accepted by older nodes.
The solution of having people immediately stop using client version v0.8 is hoped to lead to a resolution of this in a timely manner. By enforcing the use of the v0.7 client version it is hoped that side of the fork will assert dominance; this will happen when the v0.7 Blockchain exceeds the v0.8 Blockchain in length—at the time of writing a difference between 225436 (in v0.7) and 225446 (in v0.8.) Until v0.7 overtakes v0.8 the problem will persist.
What can people expect to happen right now and afterwards?
In the wake of these emergency proceedings, MtGox has temporarily suspended deposits; but trades are still occurring as usual. Exchange rate dropped very quickly and is still falling (as expected as an overreaction to the crisis.) Chances are good that many Bitcoin exchanges will follow suit with MtGox–who control a vast majority of current exchanges–and stop accepting deposits for a short while as the Blockchains are sorted out.
Miners have quickly gotten on board with dropping v0.8 in favor of v0.7 to assist the dominance of the proper Blockchain and this will not affect consumers of Bitcoin—even after the dominance of the proper chain switches.
What the aftermath will bring is still unknown. The triggering of a fork has some apparent backend implications, but culturally and for many Bitcoin consumers at the fringes will probably only notice the sudden reaction by exchanges going offline to help prevent blocks that don’t work with v0.7 from remaining at large.
Right now, Bitcoin experts assure me that once the Blockchain dominance for v0.7 is asserted it will be as if nothing happened. SiliconANGLE will work out a postmortem for everyone interested as this situation continues and resolves itself.
UPDATE: Be sure to read this update from Gavin Andresen, Bitcoin’s lead developer. It describes what happened, who the fork affects, and how it might affect them (if at all.)
UPDATE 2: Look at this animation shot of the two blockchains fighting it out in the final hours of the fork (‘correct’ chain is the one labeled as orphaned).
UPDATE 3: Blockchain fork resolved at 1:20 CST.
Latest posts by Kyt Dotson (see all)
- Bitcoin Weekly: Japanese soon pay utilities with bitcoin, U.S. Congress ‘Blockchain caucus’, IBM open-sources blockchain for enterprise - September 28, 2016
- DroneDeploy makes image uploads quicker so users in remote areas can work faster - September 27, 2016
- Node40 launches hosting for Dash blockchain governance - September 23, 2016