Topic: Alert: chain fork caused by pre-0.8 clients dealing badly with large blocks - page 13. (Read 155564 times)

I prefer that the big/most miners have the same setup (old + new version + fallback to old version).

Let me rephrase: It seems 'tested' clients are not always backwards compatible. Why not give the best test there is (real life situation) to a new version with the best fail-save there is (the previous/old version).

Whoever has an accout on arstechnica, please comment there, tell that event is over.

It is afternoon here. GMT+8

Thanks in part to the fact that noone could move BTC's into gox. :p

Now we should put the same effort to fix this:

"Dust problem":
https://bitcointalksearch.org/topic/economically-unspendable-outputs-a-problem-on-the-radar-150493

Cheers!
Thiago

No, it was night. I woke up at 3am thanks to one guy who called me over skype. I have a lot of monitoring scripts which trigger SMS alert when something bad happen on pool, but there was almost no chance to catch this, because the bug wasn't in bitcoind 0.8 used by the pool, but in previous (and still widely spread) bitcoind 0.7.

+1

plz some one remove the warning at the top of the website it mite as well read "panic panic panic sell sell sell!"

everyone can make a little fortune by betting on panic

My guess...

while this does not undermine BTC conceptually - it does open up potential, future snags of a similar nature - e.g. another sw glitch occurring with some other 3rd party component the client is using or the code itself....

since its of paramount importance this never or infrequently happens - can the devs write some integration & unit tests that push the client and its dependencies to its limits as far as the devs can see them at this point and let these tests rip on a continuous basis? I could be wrong but it sounds like this BDB issue might've been detectable... I know this kind of exhaustive testing isn't easy or even possible but given how important BTC is to the future of the USA or the world possibly.... maybe special effort should be made to the greatest extent possible to alleviate any future snafus that would give critics fodder to "rip" Bitcoin apart ....

At any rate, I'm glad the concept so far is proving out to be solid and I hope these kind of snafus happen far less often in the future.

It wasn't the size of the block that caused the problem.

Apparently from what I read, this was handled extremely well. My respect to the devs.

v 0.8 has now processed 225455

Well... Seems u r right. I hope similar scenario won't be used with political purpose though.

It's not an attack if nobody is stopping you from making transactions or getting confirmation, but just for you own safety, you need to wait out a bit longer, like wait for 30 something confirmations, etc.

This has been interesting to read.  The problem has almost corrected itself, and may be corrected by the time I press "submit".

Users never needed to downgrade.  Miners didn't really need to downgrade either.  They needed to stop producing very large blocks.  And they needed to be poked to ignore the higher block, temporarily.  [Downgrading accomplishes both, but I doubt that most miners went to that trouble.]

This all started when the lead developer one of the developers issued an "off the cuff" suggestion to enlarge the block size from 250K to 500K.  A miner went the extra step and enlarged the block to 1M, which *should* have been legal.  But there wasn't enough system and integration testing.  [There was *none* as far as I can tell with respect to this suggested change.]  Perhaps the community will learn to avoid untested changes in the future.

What prompted the suggestion to enlarge the block size?  A single site comprises some 70%+ of the traffic on bitcoin.  They are growing by leaps and bounds as bots are now doing the betting.  Whether you think SD was the "hero" for helping this bug come to light or the "villian" whose actions brought about the "off the cuff" remark and the ultimate fork is your call.  [There is plenty of heat in other threads, so let's please keep that argument out of this thread.]

It was fascinating to watch the higher block chain continue to build.  Was it ignorance by some large miners?  Or was it an intentional attempt to keep the blockchain forked.  Theoretically, this could have been fixed hours ago.  But I saw some well-known pool operators working on the chain that had (by consensus, apparently) been decreed to be the loser of the race.

Fun times.  

Block 225455   glad were all on the same chain now! Even more glad the price didnt plummet.

Asking miners to volentarily change to a different version of the client software for the good of the network = "51% attack"?  Really?  That is your tortured definition.   

How about the real one ...
https://en.bitcoin.it/wiki/Weaknesses#Attacker_has_a_lot_of_computing_power

Actually it looks like it orphaned the bad 225454 block. G'nite!