<p>The highest blockchain containing only valid blocks is always the "correct" blockchain.</p>

<p>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.</p>

<p>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.</p>

<p>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).</p>

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

CC BY-SA 3.0
2013-03-13T02:20:37.180Z
that is unfortunate, how can we ensure against something like this again, just curious
CQM
CC BY-SA 3.0
2013-03-13T02:26:07.157Z
@CQM, what's unfortunate? This behaviour is by design, and meant the problem was quickly resolved
Highly Irregular
CC BY-SA 3.0
2013-03-13T02:37:07.503Z
@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
CC BY-SA 3.0
2013-03-13T02:44:00.210Z
@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
CC BY-SA 3.0
2013-03-13T02:45:42.823Z
@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
CC BY-SA 3.0
2013-03-13T02:46:34.043Z
@CQM, I agree, and you're right to ask how this can be prevented from recurring.
Highly Irregular
CC BY-SA 3.0
2016-04-04T14:30:23.297Z
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
CC BY-SA 3.0
2013-03-12T13:43:43.663Z
2013-03-13T02:31:13.860Z
2013-03-13T02:31:13.860Z
Nicolai
<p>As a result of an <strong>"official"</strong> change in back-end databases from BDB in v0.7 to LevelDB in v0.8, in addition to an increase <em>(by some mining pools)</em> to a higher block size limit, there was <a href="http://bitcoinmagazine.com/bitcoin-network-shaken-by-blockchain-fork/" rel="nofollow">recent <strong>"hard fork"</strong></a> at blockchain height <a href="http://blockchain.info/block-height/225430" rel="nofollow">225430</a>.</p>

<p>Miners were originally told to switch back to v0.7, but then later informed that v0.8 was fine as long as they don't increase the default <em>(256kb -- soft limit)</em> block size.</p>

<p>So what happens to block <a href="http://blockchain.info/block-height/225430" rel="nofollow">225430</a> for v0.8 miners? Are they required to reload the database from &lt;<a href="http://blockchain.info/block-height/225430" rel="nofollow">225430</a> with new "max block size" limits? How did this problem supposedly just fix itself <em>(as has been reported <a href="https://bitcointalk.org/index.php?topic=152030" rel="nofollow">here</a>)</em>, or is this still a problem as blockchain.info continues to <strong>"sequentially"</strong> report orphaned blocks <a href="http://blockchain.info/orphaned-blocks" rel="nofollow">here</a>? My last question would be what happens to the transactions that were linked to block <a href="http://blockchain.info/block-height/225430" rel="nofollow">225430</a> <em>(and are now UTXO)</em>, won't v0.8 still consider them spendable?</p>

<blockquote>
  <p>I'm sure this all would make a lot more sense if I had a better
  understanding of Bitcoin's block <code>reorg</code> logic. Perhaps a pseudo-code
  walk-through of the process might help.</p>
</blockquote>

<p><strong>Edit:</strong> the 2 chains seemed to have merged <a href="http://blockchain.info/block-height/225462" rel="nofollow">here</a> <em>(after 32 sequentially orphaned blocks)</em>. So how exactly did v.0.8 clients handle the reorg for 32 blocks? Is there a maximum reorg that Bitcoin can handle? Was it easier to double-spend during the 5+ hour blockchain correction?</p>

CC BY-SA 3.0
2013-03-15T10:26:31.170Z
@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.
Shomari
CC BY-SA 3.0
2016-07-09T22:54:29.113Z
Maybe worth pointing out that [BIP50](https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki), an effort to learn lessons from the event, [had the term "hard fork" removed](https://github.com/bitcoin/bips/commit/072173f3c5290a355e5696b669c3703fcdd47ae3) 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
<blockchain><mining-pools><blockchain-fork><march-2013-fork>
How was the blockchain's "hard fork" automatically resolved?
Shomari
# How was the blockchain's "hard fork" automatically resolved?

(Asked by: username_0 on 2013-03-12)

As a result of an **"official"** change in back-end databases from BDB in v0.7 to LevelDB in v0.8, in addition to an increase *(by some mining pools)* to a higher block size limit, there was [recent **"hard fork"**](http://bitcoinmagazine.com/bitcoin-network-shaken-by-blockchain-fork/) at blockchain height [225430](http://blockchain.info/block-height/225430).

Miners were originally told to switch back to v0.7, but then later informed that v0.8 was fine as long as they don't increase the default *(256kb -- soft limit)* block size.

So what happens to block [225430](http://blockchain.info/block-height/225430) for v0.8 miners? Are they required to reload the database from <[225430](http://blockchain.info/block-height/225430) with new "max block size" limits? How did this problem supposedly just fix itself *(as has been reported [here](https://bitcointalk.org/index.php?topic=152030))*, or is this still a problem as blockchain.info continues to **"sequentially"** report orphaned blocks [here](http://blockchain.info/orphaned-blocks)? My last question would be what happens to the transactions that were linked to block [225430](http://blockchain.info/block-height/225430) *(and are now UTXO)*, won't v0.8 still consider them spendable?

> I'm sure this all would make a lot more sense if I had a better
> understanding of Bitcoin's block `reorg` logic. Perhaps a pseudo-code
> walk-through of the process might help.

**Edit:** the 2 chains seemed to have merged [here](http://blockchain.info/block-height/225462) *(after 32 sequentially orphaned blocks)*. So how exactly did v.0.8 clients handle the reorg for 32 blocks? Is there a maximum reorg that Bitcoin can handle? Was it easier to double-spend during the 5+ hour blockchain correction?

**Tags:** blockchain, mining-pools, blockchain-fork, march-2013-fork

> **Comments:**
> **username_0**: @username_2 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.  
> **username_1**: Maybe worth pointing out that [BIP50](https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki), an effort to learn lessons from the event, [had the term "hard fork" removed](https://github.com/bitcoin/bips/commit/072173f3c5290a355e5696b669c3703fcdd47ae3) 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.  

---

## 1 answers

### Answer by username_2 on 2013-03-12. Score: 5

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

> **Comments:**
> **username_3**: that is unfortunate, how can we ensure against something like this again, just curious  
> **username_4**: @username_3, what's unfortunate? This behaviour is by design, and meant the problem was quickly resolved  
> **username_3**: @username_4 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  
> **username_4**: @username_3, 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.  
> **username_3**: @username_4 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  
> **username_4**: @username_3, I agree, and you're right to ask how this can be prevented from recurring.  
> **username_5**: 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.  

---

