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

[Parazyd]

Come on... Stop panicking. It's a okay.

[Jan]

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

MultiBit should be able to handle re-orgs of depth 50, so I guess you are fine.

[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:

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

Isn't there written about 51% attack?

• If you're a miner, please do not mine on 0.8 code. Stop, or switch back to 0.7. BTCGuild is switching to 0.7, so the old chain will get a majority hash rate soon.

[prophecynine]

Phew!

Nice work everyone. This really shows the resilience of bitcoins.

[zvs]

well, one more until it re-orgs for me

ok, there

2013-03-12 06:20:30 received block 000000000000016924f85069603be8164578eedf113f44d60bf0438cba047c7f
2013-03-12 06:20:30 REORGANIZE: Disconnect 25 blocks; 0000000000000366ce98ca28338900094e8cbf445776253181749f782546d006..0000000000000 0df96f272c3b1e9dd15272b55750966cbd239219b94756c73ec
2013-03-12 06:20:30 REORGANIZE: Connect 26 blocks; 0000000000000366ce98ca28338900094e8cbf445776253181749f782546d006..0000000000000 16924f85069603be8164578eedf113f44d60bf0438cba047c7f
2013-03-12 06:20:34 Committing 28586 changed transactions to coin database...

[dscotese]

I there was going to be fireworks??

[Bitobsessed]

well, one more until it re-orgs for me

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

[DeathAndTaxes]

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

Attacker has a lot of computing power
An attacker that controls more than 50% of the network's computing power can, for the time that he is in control, exclude and modify the ordering of transactions. This allows him to:
Reverse transactions that he sends while he's in control. This has the potential to double-spend transactions that previously had already been seen in the block chain.
Prevent some or all transactions from gaining any confirmations
Prevent some or all other miners from mining any valid blocks

[imardern]

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

[Blowfeld]

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.  

[oakpacific]

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.

Isn't there written about 51% attack?

• If you're a miner, please do not mine on 0.8 code. Stop, or switch back to 0.7. BTCGuild is switching to 0.7, so the old chain will get a majority hash rate soon.

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.

[Come-from-Beyond]

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.   

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

[hmmmstrange]

v 0.8 has now processed 225455

[Herodes]

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

[justusranvier]

This all started when the lead developer 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.

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

The presence of a 250k arbitrary block limit prevented the underlying problem of the db from being discovered until that moment when a perfect storm composed out of a db upgrade and the limit removal created two almost equal miner bases. This could have easily been avoided by simply not relying on magic numbers. It will ever be the case that whenever code contains arbitrary numbers based on arbitrary assumptions that code will break spectacularly.

That is not correct.  v0.7 nodes accepted a 1MB block on testnet.  The issue was more complex then just the size of the block.  By the protocol the block which was rejected by some nodes SHOULD have been accepted.  The 250kb soft limit was simply a default for block construction.  Even with it in place nodes should have accepted properly constructed blocks up to the 1MB limit.  It also appears not all v0.7 nodes were affected.  Some accepted the problem block and some didn't.  The defect/limit in BDB wasn't documented and didn't occur in all versions/platforms.   It appears the number of transactions being changed as a result of the block validation crossed some "magic code" not in the Bitcoin source code but undocumented in some implementations of BDB.

v0.7 reliance on BDB caused it to be fundamentally broken/flawed. Its actions weren't consistent with the documented protocol, the higher level source code, or anyone's understanding/expectation of what should have happened.   Nobody was saying/thinking oh yeah if you make a block with more than x transaction it will abort, cause a rollback, and result in a rejection.  It was a landmine.  

[BalkanBoy]

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.

[BTC-Fawkes]

My guess...

[luffy]

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

everyone can make a little fortune by betting on panic

[Quantus]

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

[Herodes]

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

+1