Anything with more than 11 confirmations (at block 225446) is safe, anything with less may or may not be but all transactions will be retried so bar intended harm there should be no issue for users.
Just don't trust coins with less than 11 confirmations at this point, better yet, don't use your client for the next few hours at all and everything will come back to normality.
Topic: Alert: chain fork caused by pre-0.8 clients dealing badly with large blocks - page 28. (Read 155551 times)
March 11, 2013, 08:40:32 PM
March 11, 2013, 08:40:21 PM
As a user, what should I do? Should I run my 0.8 node or not? Should I revert to an older version and then run node?
March 11, 2013, 08:38:03 PM
I just got here after receiving the "urgent" message from the client. I'm a bit confused. I really hope it didn't cause major problems.
March 11, 2013, 08:37:39 PM
Coins are safe, but the current value in them is not. This will have consequences.
March 11, 2013, 08:37:15 PM
This is going to be on every nerd news website in 24 hours. What a black eye. A few people can stop bitcoin from functioning properly and not even mean to do it.
March 11, 2013, 08:37:02 PM
Just was updating to 0.8 and noticed this. Should we revert back to 0.7?
March 11, 2013, 08:36:56 PM
March 11, 2013, 08:36:32 PM
Great, so, as an end user, if we made a transaction recently, how can we tell which chain it was on?
If we made a transaction on the "new" chain and the "old" chain becomes the "main" chain, I suppose that means we'd have our bitcoins back?
This could result in disaster for transactions happening right now that will no longer be valid in the future... let's hope the exchange rate lives through this.
P.S. Which chain is blockchain.info showing?
(I just saw an urgent error message through the 0.8 client).
If we made a transaction on the "new" chain and the "old" chain becomes the "main" chain, I suppose that means we'd have our bitcoins back?
This could result in disaster for transactions happening right now that will no longer be valid in the future... let's hope the exchange rate lives through this.
P.S. Which chain is blockchain.info showing?
(I just saw an urgent error message through the 0.8 client).
March 11, 2013, 08:35:48 PM
I think what everyone wants to know is, are my coins safe? or am I holding useless 0.8 forked chain coins?
This needs to be answered please.
March 11, 2013, 08:35:22 PM
WTF BITCOIN PROTOCOL COMPROMISED???
EVERYBODY PANIC, SELL SELL SELLsince i'm such a nice guy, i'll buy your bitcoins for $20
March 11, 2013, 08:34:43 PM
I think what everyone wants to know is, are my coins safe? or am I holding useless 0.8 forked chain coins?
March 11, 2013, 08:33:45 PM
WTF BITCOIN PROTOCOL COMPROMISED???
March 11, 2013, 08:31:57 PM
wow WTF? how did this even happen, a fork due to bug?
March 11, 2013, 08:30:26 PM
And now a more elaborate explanation:
0.7 and older nodes use BDB for storing the blockchain databases. It seems this database has a limit on the size of the modification it can make atomically to the database. With the larger blocks of the past days, it seems to have triggered the limit. The result is that 0.7 (by default, it can be tweaked manually) will not accept "too large" blocks (we don't yet know what exactly causes it, but it is very likely caused by many transactions in the block). Specifically, block
000000000000015c50b165fcdd33556f8b44800c5298943ac70b112df480c023 (height=225430) with >1700 transactions.
However. 0.8 (which uses a different database system) has no such limit, and happily accepts the block. As the majority of the hash power was on 0.8, the longest chain ended up using this block, which is not accepted by older nodes.
The solution is to (for now) go back to the old chain, which has block 00000000000001c108384350f74090433e7fcf79a606b8e797f065b130575932 at height 225430.
0.7 and older nodes use BDB for storing the blockchain databases. It seems this database has a limit on the size of the modification it can make atomically to the database. With the larger blocks of the past days, it seems to have triggered the limit. The result is that 0.7 (by default, it can be tweaked manually) will not accept "too large" blocks (we don't yet know what exactly causes it, but it is very likely caused by many transactions in the block). Specifically, block
000000000000015c50b165fcdd33556f8b44800c5298943ac70b112df480c023 (height=225430) with >1700 transactions.
However. 0.8 (which uses a different database system) has no such limit, and happily accepts the block. As the majority of the hash power was on 0.8, the longest chain ended up using this block, which is not accepted by older nodes.
The solution is to (for now) go back to the old chain, which has block 00000000000001c108384350f74090433e7fcf79a606b8e797f065b130575932 at height 225430.
March 11, 2013, 08:29:57 PM
Hello everyone,
there is an emergency right now: the block chain has split between 0.7+earlier and 0.8 nodes. I'll explain the reasons in a minute, but this is what you need to know now:
there is an emergency right now: the block chain has split between 0.7+earlier and 0.8 nodes. I'll explain the reasons in a minute, but this is what you need to know now:
- After a discussion on #bitcoin-dev, it seems trying to get everyone on the old chain again is the least risky solution.
- 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.
- If you're a merchant: please stop processing transactions until the chains converge.
- If you're on 0.7 or older, the client will likely tell you that you need to upgrade. Do not follow this advise - the warning should go away as soon as the old chain catches up.
- If you are not a merchant or a miner, don't worry.
The original post lacked info for "regular users". Here it is:
(1) If you are a "regular user" (not a miner), the best thing is to do nothing and wait a couple hours.
(2) If you are a "regular user", upgrading, downgrading, whining, FUD, etc, will make no difference. Only miners have an incentive to do anything. Otherwise, it doesn't matter which version you are running.
(3) Regardless of who you are, your transactions are not dead, your coins are not lost. They will just temporarily be held up. If you sent a transaction within the last few hours, it may take a few more hours before it's sorted out.
(4) If you insist on processing transactions right now it's probably best to wait 30+ confirmations. It's just due diligence though ... an attacker would still need a tremendous amount of mining power, quick thinking, and a victim willing to part with a lot of BTC.
(5) By tomorrow this will be in the past and everything will appear to be normal again. If you slept through this, you'd never know that anything happend (except for the price drop).
Let me reiterate, your coins are not at risk, your transactions are not lost. It'll just take some time for the network to "iron itself out." Everything will be okay.
(1) If you are a "regular user" (not a miner), the best thing is to do nothing and wait a couple hours.
(2) If you are a "regular user", upgrading, downgrading, whining, FUD, etc, will make no difference. Only miners have an incentive to do anything. Otherwise, it doesn't matter which version you are running.
(3) Regardless of who you are, your transactions are not dead, your coins are not lost. They will just temporarily be held up. If you sent a transaction within the last few hours, it may take a few more hours before it's sorted out.
(4) If you insist on processing transactions right now it's probably best to wait 30+ confirmations. It's just due diligence though ... an attacker would still need a tremendous amount of mining power, quick thinking, and a victim willing to part with a lot of BTC.
(5) By tomorrow this will be in the past and everything will appear to be normal again. If you slept through this, you'd never know that anything happend (except for the price drop).
Let me reiterate, your coins are not at risk, your transactions are not lost. It'll just take some time for the network to "iron itself out." Everything will be okay.
Jump to: