How was the blockchain's "hard fork" automatically resolved?

The highest blockchain containing only valid blocks is always the "correct" blockchain.

The first 225430-block was accepted by 0.8 clients/miners, but due to a flaw in 0.7 clients/miners couldn't accept the block.

The 0.7-fork was accepted by all client and miners, and the 0.8-fork was only accepted by 0.8 clients/miners. The core Bitcoin developers decided they wanted the 0.7-fork to be highest, however 0.8 had the most mining power, so the developers asked mining pools to switch back to the 0.7 client.

After some time, the 0.7 blockchain (which didn't have the "flawed" transaction) was highest, and 0.8 clients/miners would treat this as being the "real" blockchain (and stop mining on the blockchain with the transaction 0.7 clients didn't accept).

The 0.8 fork is simply treat as many orphaned blocks and is not worth anything (it can't be spend, etc).

Nicolai

Posted 2013-03-12T11:42:49.823

Reputation: 1 748

1that is unfortunate, how can we ensure against something like this again, just curious – CQM – 2013-03-13T02:20:37.180

@CQM, what's unfortunate? This behaviour is by design, and meant the problem was quickly resolved – Highly Irregular – 2013-03-13T02:26:07.157

2@HighlyIrregular no, the design is that bad blocks are solved by the network without human intervention. The whole point of bitcoin is so that there is no central authority to decide the fate of the currency, as the 0.8 miners found out was not such an absolute – CQM – 2013-03-13T02:37:07.503

2@CQM, the 0.8 miners could have continued as they were if they chose, but that would have caused problems for the minority of the network running an older version. Enough of them preferred not to do this that the 0.7 version of the blockchain was intentionally chosen by the majority. Essentially, it was a vote with hashpower, which is by design. I agree it wasn't intentional for the fork to occur, but the way it was resolved was actually quite elegant, which is probably why the exchange rate is still strong. – Highly Irregular – 2013-03-13T02:44:00.210

3@HighlyIrregular I too was pleased with the outcome, but this does raise concerns, especially for a solo miner that would prefer a hands off approach. Miners and merchants alike would need an automated alert – CQM – 2013-03-13T02:45:42.823

@CQM, I agree, and you're right to ask how this can be prevented from recurring. – Highly Irregular – 2013-03-13T02:46:34.043

It was not a vote of hashpower choosing one chain over another. It was hashpower choosing to either continue as two chains or as one. The 0.7 chain was the only one compatible with all software out there, so it was the only possible choice if they didn't want to have a permanent fork. – Pieter Wuille – 2016-04-04T14:30:23.297

@Nicolai thanks for the answer, but I was really looking for a lot more detail as to WHY & HOW? blockchain.info shows the first non-forked block was http://blockchain.info/block-height/225462, 32 blocks after the "hard fork". So what happened to v0.8 clients and their 32 previously confirmed blocks (as in what happened "technically" in the v0.8 client when the chains merged at height 225462 and v0.8 now had the "wrong" chain)? Also, what's the longest "hard-fork" Bitcoin can withstand? I'm really looking for "technical" details. Thanks.

– nyusternie – 2013-03-15T10:26:31.170

Maybe worth pointing out that BIP50, an effort to learn lessons from the event, had the term "hard fork" removed since the problem ultimately turned out not to be a new software version relaxing the rules. For more "hard fork or not?" detail see https://bitcoin.stackexchange.com/q/36090.

– ZakW – 2016-07-09T22:54:29.113

How was the blockchain's "hard fork" automatically resolved?

Answers