https://bitcointalksearch.org/topic/alert-chain-fork-caused-by-pre-08-clients-dealing-badly-with-large-blocks-152030
Locking this...
Topic: Anyone mining on 0.8 - URGENT!! (Read 1556 times)
so another potentially stupid question: what if we're not mining and we're just upgrading our client to 0.8? Is that ok?
From what I have gathered scanning #bitcoin-dev - OK to run 0.8 if you are NOT mining against it.
Ok, for the sake of us uniformed idiots, just what the hell is your point?!?!?!?
Please enunciate your syllables as accurately as possible.
so another potentially stupid question: what if we're not mining and we're just upgrading our client to 0.8? Is that ok?
From what I have gathered scanning #bitcoin-dev - OK to run 0.8 if you are NOT mining against it.
thanks lots for quick response!
Updated OP
so another potentially stupid question: what if we're not mining and we're just upgrading our client to 0.8? Is that ok?
From what I have gathered scanning #bitcoin-dev - OK to run 0.8 if you are NOT mining against it.
Based on the text, it would seem that 750k is not OK.
I understand. My question should have been phrased:
Is 500k the real limit we should follow for now or was that just a quick conservative number while the issue is being researched? (I have another source that suggests the real limit is 998k).
so another potentially stupid question: what if we're not mining and we're just upgrading our client to 0.8? Is that ok?
That is okay. Do not accept transactions as non-reversible until these forks are sorted out. The only major point: DO NOT MINE (or send work to) BITCOIND v0.8 
https://mtgox.zendesk.com/entries/21477395-Bitcoin-blockchain-issue-bitcoin-deposits-temporarily-suspended
"Due to an issue with the Bitcoin blockchain, all bitcoin deposits to MtGox are temporarily suspended.
This will be the case until the Bitcoin issue with the blockchain is resolved.
More details: http://sourceforge.net/mailarchive/message.php?msg_id=30587843
Bitcoin deposited with MtGox or in transit are safe. We disabled deposits because this condition makes it easier for an attacker to perform some kind of attacks Bitcoin is designed to prevent. Once the situation is back to normal, we will resume accepting deposits, and all deposits done in the meantime will be confirmed too.
UPDATE: Miners are encouraged to downgrade to Bitcoin 0.7.2 - at least temporarily - to push the correct blockchain forward. Once the correct blockchain is longer than the 0.8-only blockchain, we will be able to resume bitcoin transactions."
"Due to an issue with the Bitcoin blockchain, all bitcoin deposits to MtGox are temporarily suspended.
This will be the case until the Bitcoin issue with the blockchain is resolved.
More details: http://sourceforge.net/mailarchive/message.php?msg_id=30587843
Bitcoin deposited with MtGox or in transit are safe. We disabled deposits because this condition makes it easier for an attacker to perform some kind of attacks Bitcoin is designed to prevent. Once the situation is back to normal, we will resume accepting deposits, and all deposits done in the meantime will be confirmed too.
UPDATE: Miners are encouraged to downgrade to Bitcoin 0.7.2 - at least temporarily - to push the correct blockchain forward. Once the correct blockchain is longer than the 0.8-only blockchain, we will be able to resume bitcoin transactions."
so another potentially stupid question: what if we're not mining and we're just upgrading our client to 0.8? Is that ok?
Thanks for sharing your amazing knowledge of which number is bigger. We are all enlightened.
I was referring to this:
Quote
When you start again in a few hours, you should set your maxblocksize to 500k or less.
Based on the text, it would seem that 750k is not OK.
Thanks for sharing your amazing knowledge of which number is bigger. We are all enlightened.
Anyone know if 750k is ok?
My guess is that it is fine:
http://blockchain.info/block-index/356435/00000000000002707802d1a7ed26e04f720578ada6cc8f2f0d2a1d040dfc2491
Anyone know if 750k is ok?
[20:12] Everybody mining on version 0.8 should stop mining for now. When you start again in a few hours, you should set your maxblocksize to 500k or less.
http://sourceforge.net/mailarchive/forum.php?thread_name=CAPg%2BsBjm%2Be%3DA%2BedSRHXU7JSqyfSc4hou_SRdQHF48xhKQGA4zA%40mail.gmail.com&forum_name=bitcoin-development
http://sourceforge.net/mailarchive/forum.php?thread_name=CAPg%2BsBjm%2Be%3DA%2BedSRHXU7JSqyfSc4hou_SRdQHF48xhKQGA4zA%40mail.gmail.com&forum_name=bitcoin-development
Quote
Hello again,
block 000000000000015c50b165fcdd33556f8b44800c5298943ac70b112df480c023 (height=225430) seems indeed to have cause pre-0.8 and 0.8 nodes to fork (at least mostly). Both chains are being mined on - the 0.8 one growing faster.
After some emergency discussion on #bitcoin-dev, it seems best to try to get the majority mining power back on the "old" chain, that is, the one which 0.7 accepts (with 00000000000001c108384350f74090433e7fcf79a606b8e797f065b130575932 at height 225430). That is the only chain every client out there will accept. BTC Guild is switching to 0.7, so majority should abandon the 0.8 chain soon.
Short advice: if you're a miner, please revert to 0.7 until we at least understand exactly what causes this. If you're a merchant, and are on 0.8, stop processing transactions until both sides have switched to the same chain again. We'll see how to proceed afterwards.
--
Pieter
On Tue, Mar 12, 2013 at 1:18 AM, Pieter Wuille <[email protected]> wrote:
Hello everyone,
Í've just seen many reports of 0.7 nodes getting stuck around block 225430, due to running out of lock entries in the BDB database. 0.8 nodes do not seem to have a problem.
In any case, if you do not have this block:
2013-03-12 00:00:10 SetBestChain: new best=000000000000015aab28064a4c521d6a5325ff6e251e8ca2edfdfe6cb5bf832c height=225439 work=853779625563004076992 tx=14269257 date=2013-03-11 23:49:08
you're likely stuck. Check debug.log and db.log (look for 'Lock table is out of available lock entries').
If this is a widespread problem, it is an emergency. We risk having (several) forked chains with smaller blocks, which are accepted by 0.7 nodes. Can people contact pool operators to see which fork they are on? Blockexplorer and blockchain.info seem to be stuck as well.
Immediate solution is upgrading to 0.8, or manually setting the number of lock objects higher in your database. I'll follow up with more concrete instructions.
If you're unsure, please stop processing transactions.
--
Pieter
block 000000000000015c50b165fcdd33556f8b44800c5298943ac70b112df480c023 (height=225430) seems indeed to have cause pre-0.8 and 0.8 nodes to fork (at least mostly). Both chains are being mined on - the 0.8 one growing faster.
After some emergency discussion on #bitcoin-dev, it seems best to try to get the majority mining power back on the "old" chain, that is, the one which 0.7 accepts (with 00000000000001c108384350f74090433e7fcf79a606b8e797f065b130575932 at height 225430). That is the only chain every client out there will accept. BTC Guild is switching to 0.7, so majority should abandon the 0.8 chain soon.
Short advice: if you're a miner, please revert to 0.7 until we at least understand exactly what causes this. If you're a merchant, and are on 0.8, stop processing transactions until both sides have switched to the same chain again. We'll see how to proceed afterwards.
--
Pieter
On Tue, Mar 12, 2013 at 1:18 AM, Pieter Wuille <[email protected]> wrote:
Hello everyone,
Í've just seen many reports of 0.7 nodes getting stuck around block 225430, due to running out of lock entries in the BDB database. 0.8 nodes do not seem to have a problem.
In any case, if you do not have this block:
2013-03-12 00:00:10 SetBestChain: new best=000000000000015aab28064a4c521d6a5325ff6e251e8ca2edfdfe6cb5bf832c height=225439 work=853779625563004076992 tx=14269257 date=2013-03-11 23:49:08
you're likely stuck. Check debug.log and db.log (look for 'Lock table is out of available lock entries').
If this is a widespread problem, it is an emergency. We risk having (several) forked chains with smaller blocks, which are accepted by 0.7 nodes. Can people contact pool operators to see which fork they are on? Blockexplorer and blockchain.info seem to be stuck as well.
Immediate solution is upgrading to 0.8, or manually setting the number of lock objects higher in your database. I'll follow up with more concrete instructions.
If you're unsure, please stop processing transactions.
--
Pieter
Jump to: