Topic: Alert: chain fork caused by pre-0.8 clients dealing badly with large blocks - page 24. (Read 155551 times)
March 11, 2013, 09:30:01 PM
I shut off my miners and now the house is getting cold. I haven't used the furnace in over a year. I hope it still works.
March 11, 2013, 09:29:51 PM
This will blast all over tech sites tmr.
This will have consequences on the price. Negatively i bet.
This will have consequences on the price. Negatively i bet.
On the bright side many people cannot even sell their coins so the price is not going down as quick as it could have. :-)
March 11, 2013, 09:28:39 PM
what happens to users who do not upgrade?
They cannot use Bitcoin anymore. If you're going to run a Bitcoin client, you have to keep it up to date and follow announcements. Otherwise, all kinds of terrible things can happen.Quote
and if bitcoin requires such drastic hand holding shouldn't this be programmed into the client? some type of ksplice like update?
It is vital that the decision to make this kind of change in the Bitcoin protocol be consciously made. What if the next change is to keep the block reward at 25 bitcoins forever? How easy do you want that to be? March 11, 2013, 09:28:07 PM
So this will require a "forced switch" to the "correct block chain", but who exactly has the power to do this?
March 11, 2013, 09:27:04 PM
High time that all the companies going around Bitcoin should devote time, money and resources to core bitcoin development and testing.
March 11, 2013, 09:26:32 PM
This will blast all over tech sites tmr.
This will have consequences on the price. Negatively i bet.
This will have consequences on the price. Negatively i bet.
March 11, 2013, 09:25:09 PM
*in a few hours 
March 11, 2013, 09:25:03 PM
Any idea what version eligius is on?
EDIT: Luke Jr has confirmed that Eligius is currently running 0.6.0 so it's safe to mine there too.
EDIT: Luke Jr has confirmed that Eligius is currently running 0.6.0 so it's safe to mine there too.
March 11, 2013, 09:23:43 PM
So if I pet 500 BTC on SatoshiDice and lose, later on, I get my coins back? Conversely, if I win big, I won't be getting those coins.
March 11, 2013, 09:23:24 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.
Just to ask a couple of questions.
Could this have been deliberate in any way in that someone, or group, figured out the weakness of the 0.7 client?
Is this just a random occurrence with some ASIC's coming online and Hash rate going up?
In my ignorant opinion, seems to me that if it was known the 0.7 had a dbase limit then that client should have been voted off the network a while ago.
For the newbie fun I just did a cash deposit on Gox. Was like WOW look at these prices, bought then couldn't transfer to BTCe and finally got wise looking at the chat feed there. Thankfully, I was able to back out on Gox and go back to cash at just a little loss.
From what I can tell this problem was not caused by a malformed transaction, but by a malformed, mined block. If an attacker crafted a bad block, they would have to do so as a miner which would take an awful lot of patience or resources, so I don't think it was intentional.
As to why this wasn't caught in testing, that's a great question but I'll bet it's a tricky kind of bug specific to BDB that is hard to replicate if you aren't looking for it. Once the mess is cleaned up, and once we carve a clear upgrade path to 0.8 and beyond we'll be leaving BDB and it's bugfest behind, though.
March 11, 2013, 09:18:32 PM
And why are we downgrading and not pushing 0.8 fork if bug is in 0.7 ?
I'm also wondering this. I'll upgrade right now if that will help fix the issue.
Can anyone answer if deepbit is on .7 or .8 code?
March 11, 2013, 09:23:04 PM
Will it ever be possible to upgrade to a client which can support these large blocks? Seems to me we're going to be stuck like this.
Yeah, through a coordinated process. Most likely it will go like this:1) We'll pick a block number on which to switch.
2) A new .8 version will be released the switches as of that block number.
3) It will be announced that everyone must update before that block number.
4) The switch will take place automatically.
what happens to users who do not upgrade?
and if bitcoin requires such drastic hand holding shouldn't this be programmed into the client? some type of ksplice like update?
They will be left in the dust, as it is their bug. They cannot claim that the fork is against Bitcoin's spirit. This is similar to a previous hard-fork where the old chain allowed negative transaction fees, except the initial remedy is reversed. The long-term remedy is the same.
March 11, 2013, 09:22:51 PM
Will it ever be possible to upgrade to a client which can support these large blocks? Seems to me we're going to be stuck like this.
Yeah, through a coordinated process. Most likely it will go like this:1) We'll pick a block number on which to switch.
2) A new .8 version will be released the switches as of that block number.
3) It will be announced that everyone must update before that block number.
4) The switch will take place automatically.
what happens to users who do not upgrade?
and if bitcoin requires such drastic hand holding shouldn't this be programmed into the client? some type of ksplice like update?
That would destroy any semblance of decentralization that remains.
March 11, 2013, 09:21:12 PM
Will it ever be possible to upgrade to a client which can support these large blocks? Seems to me we're going to be stuck like this.
Yeah, through a coordinated process. Most likely it will go like this:1) We'll pick a block number on which to switch.
2) A new .8 version will be released the switches as of that block number.
3) It will be announced that everyone must update before that block number.
4) The switch will take place automatically.
what happens to users who do not upgrade?
and if bitcoin requires such drastic hand holding shouldn't this be programmed into the client? some type of ksplice like update?
March 11, 2013, 09:19:39 PM
And why are we downgrading and not pushing 0.8 fork if bug is in 0.7 ?
Because 0.8 can accept the blocks generated by 0.7, 0.7 cannot accept the blocks generated by 0.8.
So on the one hand, enough miners can backpedal to make sure the 0.7 chain wins until we fix the problem, meaning everyone gets to stay on the same page, or we try to lean on the 0.8 block which will leave half or more of the world's miners and nodes on the wrong side of the fork until they all upgrade.
March 11, 2013, 09:18:43 PM
Will it ever be possible to upgrade to a client which can support these large blocks? Seems to me we're going to be stuck like this.
Yeah, through a coordinated process. Most likely it will go like this:1) We'll pick a block number on which to switch.
2) A new .8 version will be released the switches as of that block number.
3) It will be announced that everyone must update before that block number.
4) The switch will take place automatically.
March 11, 2013, 09:18:43 PM
great.... just did a transaction a couple hours ago.
You'll be fine, I did one 45 minutes ago and it's cleared. March 11, 2013, 09:18:20 PM
Sounds like before block 225430 all coins are safe.
I'm on 0.8.0 client and block 225451... this implies at this moment the last 21 confirmations are not safe. Ugh.
So if everyone switches to 0.7 those people on 0.8.0 need to rely on more than the typical 6 confirmations.
What version is Slush's pool on?
I'm on 0.8.0 client and block 225451... this implies at this moment the last 21 confirmations are not safe. Ugh.
So if everyone switches to 0.7 those people on 0.8.0 need to rely on more than the typical 6 confirmations.
What version is Slush's pool on?
March 11, 2013, 09:17:37 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.
Just to ask a couple of questions.
Could this have been deliberate in any way in that someone, or group, figured out the weakness of the 0.7 client?
Is this just a random occurrence with some ASIC's coming online and Hash rate going up?
In my ignorant opinion, seems to me that if it was known the 0.7 had a dbase limit then that client should have been voted off the network a while ago.
For the newbie fun I just did a cash deposit on Gox. Was like WOW look at these prices, bought then couldn't transfer to BTCe and finally got wise looking at the chat feed there. Thankfully, I was able to back out on Gox and go back to cash at just a little loss.
March 11, 2013, 09:17:22 PM
Sent a lodgement to a well known BTC marketplace just before this hit, from a .7.2 Beta client. Obviously gone from the client but will it ever confirm and if no can I recover em?
Yes. This problem was with the formation of one block, and a block is naught but a container of transactions. All the same transactions are still being put into blocks by the 0.7 miners. The wallet version you run is completely unrelated to the problem, this problem only pertains to the version of mining software. AFAWCT absolutely all transactions will be handled properly, save the block rewards for the miners who mine into the losing chain of course.
*now gets it*
Slow on the uptake there, its late here ^^ Thanks for your explanation
Jump to: