Alert: chain fork caused by pre-0.8 clients dealing badly with large blocks

[Bitobsessed]

3 more...come on!

[jgarzik]

Please explain how the timestamp of block 225449(2013-03-12 05:30:02) is before block 225448(2013-03-12 05:33:45)?

It is permitted within the spec that one block may set its 'nTime' field before a previous block... but always within a certain range of time.

[freequant]

Damn, Bitcoin is so kickass resilient. I want to see how Mastercard, Visa or Amex would manage to fork a network problem into another dimension and continue processing transactions as if nothing happened while the network self organizes to route around the issue. That accident could seem like negative PR for Bitcoin, but by the time the dust settles, bystanders can only be impressed by the insolent lack of consequences of this global network outage.

[justusranvier]

Just another reorg. NBD

[JoelKatz]

Please explain how the timestamp of block 225449(2013-03-12 05:30:02) is before block 225448(2013-03-12 05:33:45)?

There's no sane way to enforce timestamps. Say someone mines a block that you think has a time three minutes in the future, what do you do? Do you ignore it? Do you deliberately set your time even further in the future and try to mine a block with a time you believe is wrong?

[oakpacific]

1 more block, go,go,go!

[whitslack]

Difficulty is adjusted every ~2000 (ed2: 2016... I think.  hah) blocks.  I suppose some people could keep going on the orphaned side, but it won't matter anymore (after this pre 0.8 side catches up)....  

Wouldn't happen. The 0.8 miners will immediately notice that the 0.7 chain has become the main chain and will switch to it. One of them could still produce another problematic block, but it would just be an ordinary orphan, not a fork.

[keystroke]

1 more until matched. 2 until reorg.

[gmaxwell]

0.8 is not flawed. The flaw lied in 0.7 and below. If an upgrade was hastened, the problem would not have been a problem at all.

Sadly, 0.8 is flawed— its "one job" was to faithfully follow the behavior of 0.7, "bugs" and all. It did not. Had we known about this behavior in 0.7 or had testing turned it up we would have made sure 0.8 behaved the same way.
This is the nature of a distributed consensus system.  The primary definition of right and wrong is "consistent" and if you aren't consistent you aren't right, no matter what.

The testing should have happened with the older version of Bitcoin. I don't see how testing 0.8 would fix this issue, given that 0.8 fixes the bug.

It was. Many of the tests we do are consistency checks: we take two nodes (old version + new version) through the same sequence of blocks and reorganizations and make sure they agree along every step of the way. So both old and new are tested at once because consistency is the most important behavior characteristic.

If you'd like to contribute, testing is an area where we can basically have an infinite amount of additional resources and put them all to good use.

[DoomDumas]

Damn, Bitcoin is so kickass resilient. I want to see how Mastercard, Visa or Amex would manage to fork a network problem into another dimension and continue processing transactions as if nothing happened while the network self organizes to route around the issue. That accident could seem like negative PR for Bitcoin, but by the time the dust settles, bystanders can only be impressed by the insolent lack of consequences of this global network outage.

Indeed !

Very true.. Im also quite impressed about BTC resilience

[justusranvier]

If you'd like to contribute, testing is an area where we can basically have an infinite amount of additional resources and put them all to good use.

If I set up a node on testnet to CPU mine and just left it would that be helpful, or does it need to be monitored? 

[Bitobsessed]

Please explain how the timestamp of block 225449(2013-03-12 05:30:02) is before block 225448(2013-03-12 05:33:45)?

There's no sane way to enforce timestamps. Say someone mines a block that you think has a time three minutes in the future, what do you do? Do you ignore it? Do you deliberately set your time even further in the future and try to mine a block with a time you believe is wrong?

So it depends on the time that is set on the server?

Please explain how the timestamp of block 225449(2013-03-12 05:30:02) is before block 225448(2013-03-12 05:33:45)?

It is permitted within the spec that one block may set its 'nTime' field before a previous block... but always within a certain range of time.

And depending on the differences in server times the spec was written to allow minor differences in server timestamps?

Correct?

[candoo]

Is this issue fixed or do we still have 2 blockchains running?

[redbeans2012]

Is this issue fixed or do we still have 2 blockchains running?

Looks like 1 or 2 blocks and the fork will be fixed.

[Jan]

Bam!

[Come-from-Beyond]

Is this issue fixed or do we still have 2 blockchains running?

Fixed? U call 51% attack organized by Bitcoin Foundation "a fix"? :facepalm:

[farproc]

0.7 is catching up??

[DeathAndTaxes]

Is this issue fixed or do we still have 2 blockchains running?

Fixed? U call 51% attack organized by Bitcoin Foundation "a fix"? :facepalm:

What 51% attack?  Do you even know what "51% attack" means?  Hint: it isn't the Bitcoin equivalent of the boogeyman.

[Jan]

Bam!

We are on 0.7 now: https://blockchain.info/en/orphaned-blocks

[Amitabh S]

If we use blockchain.info wallet, I guess we don't have to worry.
Will Multibit be affected?