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

[makomk]

It's actually about half of that. About half of those people shouldn't have found blocks and only did because the person who should have mined the block was working on the other chain.

Think about it this way, for each block in the fork, someone mined the block in the 0.7 chain and someone mined it in the 0.8 chain. About half the time, the right person got it (because the forks merged when the work in them was roughly equal), and they still have it. About half the time, the wrong person got it and the right person lost it in an orphaned block.

That's not true. Think about it this way - the difficulty didn't change, so on average everyone mined about the same number of blocks as they would have if the blockchain hadn't forked, except that all the blocks on the losing side of the fork were orphaned and the people mining them didn't get paid. If it wasn't for the fork the blocks would have been distributed slightly differently amongst the miners on the losing side and they might have received very slightly more or less, but since it could vary in either direction we can safely say they're out 625BTC or 29k$. (This also means all miners on the losing side of the fork lost money even if none of their blocks were orphaned, since they could potentially have mined blocks if the chain hadn't forked.)

[1714550323]

1714550323

[1714550323]

1714550323

[1714550323]

1714550323

[becoin]

The only question is when does it happen and who will lose out because of it.

The really important question is what would have happened if there wasn't a coordinated effort to help the "correct" fork?

[trainhappy]

Would you all calm down.... This issue only affects miners and merchants.

I'm not a miner or a merchant, what should I do?

Nothing. Your bitcoin software will switch to the correct chain automatically, no matter which version you are running.

- http://bitcoin.org/chainfork.html

Transactions are going through fine according to https://coinbase.com/network its not the end, so just relax....

[piotr_n]

The only question is when does it happen and who will lose out because of it.

The really important question is what would have happened if there wasn't a coordinated effort to help the "correct" fork?

The longer one would have won.
Depending on how much power is already at the new clients, this could have disabled the old clients from the network - made them obsolete.
Which maybe would have been a good thing, considering that this needs to happen anyway, if we don't want to wait weeks for our transactions to get mined, in a month time or so.

[chooser]

To be accurate, it wasn't "the lead developer" who suggested raising the block size limit, it was me. I am a Bitcoin developer, but Gavin is the lead. So you can blame me if you like.

Thank you for rising the block size limit. This is something that had to be done. Thanks to you we know this issue and now we can expect that it will be done in a safer way in the future.

Moreover we all know that we're using an experimental currency, and funny things might happen.

[benjamindees]

By definition, a *unexpected* difference in behavior between the old client and the new client is a bug in the new client.

Props to everyone who recognized this and did the right thing to correct it.  This only strengthens my faith in Bitcoin.

How can we prevent this from happening in the future and is there any other way the average user can contribute to the robustness of bitcoin?

Keep your software updated.

Terrible advice for a project like Bitcoin.

From what I can gather it seems to me like the database used by 0.8 is much more superior, so it will be used. But in order to patch 0.8 it seems like an artificial cap will be placed on the block size so that 0.8.1 is compatible with older versions.

This sounds like the way forward.

[Luke-Jr]

The only question is when does it happen and who will lose out because of it.

The really important question is what would have happened if there wasn't a coordinated effort to help the "correct" fork?

The longer one would have won.

No. A majority of miners cannot effect a change in protocol rules.
A hard fork like this would require the intentional support of a majority of merchants.
Short of an emergency, that means everyone will be given at least 2 years to upgrade.

[arruah]

Please explain to me whether I'm on my pool is now updated to version 0.8?

[PawShaker]

The only question is when does it happen and who will lose out because of it.

The really important question is what would have happened if there wasn't a coordinated effort to help the "correct" fork?

It is important to keep in mind that this kind of problems are rare and have been already been thought about. Bitcoin as whole is resilient against this kind of problems. When two versions of Bitcoin nodes cannot agree on interpretation of the rules then miners vote with their feet. They either upgrade or downgrade.

The only thing interesting about this incident is that a small group of most potent miners have changed the outcome by dumping their version. It seems that at the beginning version 0.8 was winning and everyone would be forced to upgrade to that version on very short notice. Only when operators of big pools decided to downgrade, branch on which version 0.7 worked took over.

The issue got everyone by surprise mainly because old version (0.7) had a surplus rule/feature limiting block size. Was problem known before, developers would first release a version which accepts large blocks but does not produce them. Only when almost everyone would upgrade to that version, large blocks would be produced.

Actually this is what we are having now. Version 0.8 with default configuration accepts large blocks but does not produce them.

[piotr_n]

A hard fork like this would require the intentional support of a majority of merchants.

Sure. But how is it unintentional to accept blocks longer than 250KB, after the "majority" (expressed in the hashing power) upgraded their clients to a version that accepts blocks larger than 250KB?
And they upgraded it not because they had no reason - they actually had a very good reason.

[FreedomCoin]

i have a bunch of unconfirmed bitcoins when i reverted back to 0.8

[piotr_n]

i have a bunch of unconfirmed bitcoins when i reverted back to 0.8

did you try to start it with "-rescan"?

[FreedomCoin]

i have a bunch of unconfirmed bitcoins when i reverted back to 0.8

did you try to start it with "-rescan"?

How do i do a -rescan? Yesterday after downgrading to 0.7 i got a cannot read blkindex.dat... now that i reverted back to 0.8 now more than half of my wallet is unconfirmed.

should i delete the blkindex.dat and the blk000x.dat files?

[piotr_n]

How do i do a -rescan?

when you start bitcoin-qt (or bitcoin-qt.exe) add -rescan to the command line.
it will take much longer to start, but all the transactions inside your wallet should eventually appear confirmed, assuming that you see them confirmed at i.e. http://blockchain.info/

[benjamindees]

So what is the procedure for those (regular users) who want to continue using 0.8.0 without causing issues?  Is there a database config variable to set or something?

Downgrading seems like a bad idea for regular users.

[dree12]

So what is the procedure for those (regular users) who want to continue using 0.8.0 without causing issues?  Is there a database config variable to set or something?

Downgrading seems like a bad idea for regular users.

Don't downgrade. You aren't a concern unless you are a miner.

[BRules]

regular users don't need to do nothing, only miners should downgrade or should not increase the target block size from the default.

[FreedomCoin]

regular users don't need to do nothing, only miners should downgrade or should not increase the target block size from the default.

I thought miners "were" suppose to downgrade, but now the issue has been addressed.

[FreedomCoin]

How do i do a -rescan?

when you start bitcoin-qt (or bitcoin-qt.exe) add -rescan to the command line.
it will take much longer to start, but all the transactions inside your wallet should eventually appear confirmed, assuming that you see them confirmed at i.e. http://blockchain.info/

that fixed it, thanks for the tip... though do i need blk0001-3.dat? theres 3 files each being 2gb.

[niko]

regular users don't need to do nothing, only miners should downgrade or should not increase the target block size from the default.

Given the bdb bug, I would say miners need to upgrade to 0.8, but should not increase the blocksize (or make any changes, for that matter) until everyone has upgraded, and until more testing is done.