8

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" at blockchain 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 for v0.8 miners? Are they required to reload the database from <225430 with new "max block size" limits? How did this problem supposedly just fix itself (as has been reported here), or is this still a problem as blockchain.info continues to "sequentially" report orphaned blocks here? My last question would be what happens to the transactions that were linked to block 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 (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?

Improve this question
2
  • @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 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
    Commented Mar 15, 2013 at 10:26
  • 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 bitcoin.stackexchange.com/q/36090.
    – ZakW
    Commented Jul 9, 2016 at 22:54

1 Answer 1

Reset to default
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).

Improve this answer
7
  • 1
    that is unfortunate, how can we ensure against something like this again, just curious
    – CQM
    Commented Mar 13, 2013 at 2:20
  • @CQM, what's unfortunate? This behaviour is by design, and meant the problem was quickly resolved
    – Highly Irregular
    Commented Mar 13, 2013 at 2:26
  • 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
    Commented Mar 13, 2013 at 2:37
  • 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
    Commented Mar 13, 2013 at 2:44
  • 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
    Commented Mar 13, 2013 at 2:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.