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

[Stephen Gornick]

All transactions already have been reprocessed on new fork. [/iquote]

Has this been confirmed?  If so, source?

In fact the very first few blocks on new branch should contain all transactions in old branch.[...]The threat of double spending is theoretical, because when fork occurred there were miners working on both branches.

Sure the v0.7 nodes could have known of the transactions but there were fewer v0.7 blocks and the contents of the blocks were different from the v0.8 mined blocks.

I'm not expecting that this happened, but some of the new nodes that downgraded from v0.8 wouldn't yet have those "not-yet-onfirmed-in-v0.7" transactions in their memory pool, which opens a truck-sized hole for someone attempting a race attack.  

So I'lm not sure I'ld call it a "theoretical" risk.  If there was one or more successful double spends as a result I wouldn't be surprised, and had someone prepared in advance for this and had perfect timing and good luck, significant losses for a couple exchanges could have been the result.

[1714034704]

1714034704

[1714034704]

1714034704

[jl2012]

Yes, fixed now.

Fixed as in the chain containing the large block is now officially orphaned?

No, the 0.7 chain is still at 225441 while the 0.8 chain is 225453. Even worse, someones are stilling mining on the 0.8 chain

[evoorhees]

I personally am surprised and delighted that we move in this direction (back to the universal fork as trunk) rather than force an upgrade. 

So am I.

I thought only once banks or governments start cracking down on Bitcoin we will appreciate Bitcoins's capability of graceful degration [http://en.wikipedia.org/wiki/Fault-tolerant_system] but it only took a flaw to proove that it has that capability.

My deep respect for the devs who took this issue on and solved it. You guys made Bitcoin and my believe in it even stronger.

To blockchain eternity!

Joe

I think I kinda understand why this is a good thing, but can you explain like I'm five? Basically, why would it have been bad to let the 0.8 chain continue?

Is the reason that it'd "force" older users to upgrade and that's a mean thing to do?

[Mushoz]

Yes, fixed now.

Fixed as in the chain containing the large block is now officially orphaned?

No, the 0.7 chain is still at 225441 while the 0.8 chain is 225453. Even worse, someones are stilling mining on the 0.8 chain

So the difference increased from 11 blocks to 12 blocks? =/

[Nancarrow]

Just writing here to make part of history. "I WAS THERE" when Bitcoin shows the 2nd high level bug!  

+1. So sue me.

[mimarob]

Don't panic guys didn't you know the white nights who say Ni, has come from Wall St. (tm) to help us :-)

[whitenight639]

Yes, fixed now.

Fixed as in the chain containing the large block is now officially orphaned?

No, the 0.7 chain is still at 225441 while the 0.8 chain is 225453. Even worse, someones are stilling mining on the 0.8 chain

Is there any way us mere mortals without minig rigs can help? if we all come online with version 0.7 will it help or just create excessive traffic?


I think we should all contribute to the Devs beer and holiday fund, is there an address for this??

[ProfMac]

why the hell is Deepbit only on 0.3.21

Tycho has been very resistent to any change.

... and Luke on 0.6.0?

Eligius is actually running both 0.6.0 and 0.8.0 concurrently, but has 0.6.0 prioritized so it trumps 0.8.0 when there's a conflict.
It noticed and began reporting the problem immediately, but I guess wizkid057 was busy with something at the time.

I love this guy.

Luke -- perhaps this is a good strategy for miners to adopt. Perhaps someone should pay you (the Foundation?) to keep running like this to catch bugs quickly.

What do you call a spymaster who spies on his own spies?
Prudent.

[justusranvier]

Is there any way us mere mortals without minig rigs can help? if we all come online with version 0.7 will it help or just create excessive traffic?

If you're not mining there is nothing you can do to help, and there's no reason to downgrade to 0.7 if you already upgraded earlier.

[tvbcof]

...
I also agree that no testing of 0.8.0 could reveal the fault because the unknown fault was in 0.7.x

No amount of testing?  Really?  Seems like a slightly better than par proficiency with BerkeleyDB would have sufficed, particularly as the block size has been under relatively discussion.  Finally.  But I'm only going by what I know of the issue by skimming.

So the cautious approach of not updating paid off this time.

In my case it's more laziness than caution.  I've not built 0.8x yet and I fear that when/if I try it still won't have a functional configuration system and I'll again have to hack in the #includes I need.  But I'm not mining so it's a mute point anyway.

[evoorhees]

Yes, fixed now.

Fixed as in the chain containing the large block is now officially orphaned?

No, the 0.7 chain is still at 225441 while the 0.8 chain is 225453. Even worse, someones are stilling mining on the 0.8 chain

Is there any way us mere mortals without minig rigs can help? if we all come online with version 0.7 will it help or just create excessive traffic?


I think we should all contribute to the Devs beer and holiday fund, is there an address for this??

I don't have any mining hardware currently, but I want to contribute to the cause so I'm doing the hash algorithms by hand with pencil and paper. I then scan with OCR and email it into the blockchain.

I know ASIC's are out and all, and each hash is taking me forever, but I know I'm helping at least a little bit.

[conv3rsion]

anyway that chat log can be shared? I know a lot of people would love to read it.

 - http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/03/12  

There might have been a couple reports of issues on the 11th.  The times are UTC so this starts on the 12th.

thank you sir!

[ShireSilver]

I think I kinda understand why this is a good thing, but can you explain like I'm five? Basically, why would it have been bad to let the 0.8 chain continue?

Is the reason that it'd "force" older users to upgrade and that's a mean thing to do?

The main reason I see to go back to 0.7 instead of forcing upgrades to 0.8 is the size of the total mining pool. It should be easy for miners on 0.8 to fall back to previously used software - presumably they've all used 0.7 in the past. But miners who haven't upgraded yet haven't tested their systems on 0.8 and all manner of problems could occur making that take a long time. So we would end up with a significantly smaller amount of miners.

[justusranvier]

No amount of testing?  Really?  Seems like a slightly better than par proficiency with BerkeleyDB would have sufficed, particularly as the block size has been under relatively discussion.  Finally.  But I'm only going by what I know of the issue by skimming.

0.8 doesn't use BDB, so no amount of testing of that version would have found the problem, since the problem only exists in versions prior to 0.8.

[alexanderanon]

The price would not have rebounded so dramatically if mt gox had maintained bitcoin deposits. For every one person who wanted to sell and had coins in gox and then did sell, pushing price down to 35, there were probably at least 10 who keep their coins outside gox who were unable to sell theirs.

I actually agree that the devs handled this well and that their response is an inspiration more than anything, but the bad press tomorrow combined with the flood of (largely ignorant) sell orders once mt gox reopens deposits will certainly push the price down at least a bit.

[Nemesis]

The pools with late .7 version are fine correct?

Can someone list all the pools that are affected?

I know OZCOIN was one, but the operator quickly shut down its mining.

[420]

so it's solved it seemed. what'd i miss? just waiting for the rest of the pools to downgrade?

[jgarzik]

"no amount of testing would have found this" is a bit strong.

It is a longstanding bug that has existed through bitcoin's history, but it is certainly not impossible to test for this condition.  testnet has many test cases embedded in the chain, and this bug trigger certainly could have been one such test case.

Water under the bridge...  Satoshi had zero test cases in this original software.  Gavin and gmaxwell led the charge to start adding unit tests, and testnet blockchain tests.  BlueMatt has been working on a block tester as well.

[samurai1200]

Geez, what would have happened if the botnet threat was worse than we thought and the 0.7 chain couldn't outpace the forking 0.8? Join in the 0.8 fork?

[tvbcof]

No amount of testing?  Really?  Seems like a slightly better than par proficiency with BerkeleyDB would have sufficed, particularly as the block size has been under relatively discussion.  Finally.  But I'm only going by what I know of the issue by skimming.

0.8 doesn't use BDB, so no amount of testing of that version would have found the problem, since the problem only exists in versions prior to 0.8.

Bitcoin is a protocol and is, so far, supposed to be designed to have forward and backward compatibility.  Thorough testing would include interaction of many version.  But what I actually meant is that it is a bit surprising that the BerkeleyDB backed versions where not tested to a maximum block size (which, as I understand it, is expressed as a #DEFINE, and which, again in my understanding, was not changed between 0.7 and 0.8.)

That said, Bitcoin is still young and 'experimental' and it is fully understandable that the resources necessary to do rigorous QA are not available.  I'm not volunteering myself...although Bitcoin has the potential to make me rich enough that I probably should be...