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

[tvbcof]

So the solution is to continue to increase the block size as demand provokes this issue then?

I guess.. because what else? Are you going to appeal to people to do less transactions, hoping that it would solve the problem?
I don't believe you can i.e. convince satoshidice to drop down their lucrative business, just because other ppl's transactions are getting queued...
Why should they care anyway, if they pay the same fees as you do?
Since we don't have other solution at hand, scaling up the storage limits seems to be the only option ATM.
Unless we're OK with increasing the fees?

I'm totally OK with increasing fees.  I thought that was, by design, the way to modulate load.

If Mike is saying something like "yes, that's the way we modulate load, and yes, transactions that didn't make the cut are eventually purged, but BDB was not up to the task of processing under the currently configured garbage regime" then I'm totally down with that and feel that switching to LevelDB is an appropriate response.  But I'm not sure that is what he is saying which is why I asked.

I'm also saying that to me, working on the 'garbage collection' mechanism and/or tuning strikes me as a high priority line of development, and this seems like an opportune time to do it.  As always, as a user I hope for the highest degree of transparency as things progress.

[1714946453]

1714946453

[1714946453]

1714946453

[romerun]

well, maybe having the concept of "block" is the root of design flaw in the first place.

[piotr_n]

So the solution is to continue to increase the block size as demand provokes this issue then?

I guess.. because what else? Are you going to appeal to people to do less transactions, hoping that it would solve the problem?
I don't believe you can i.e. convince satoshidice to drop down their lucrative business, just because other ppl's transactions are getting queued...
Why should they care anyway, if they pay the same fees as you do?
Since we don't have other solution at hand, scaling up the storage limits seems to be the only option ATM.
Unless we're OK with increasing the fees?

I'm totally OK with increasing fees.

I would not mind it, either.

Whatever the community decides, I'm fine with it, as long as it solves the issue of transactions with proper fees waiting hours for the first confirmation.
The network really seems to be getting stuck already and I don't think it will just get better by itself.

[DeathAndTaxes]

You are missing the fact that it was a great opportunity to double spend any coins.
Once: you send 1000 BTC paying to merchant that uses bitcoin 0.8
Second: you pay the same 1000 BTC to another merchant who has an older client and thus is "looking" at the alternate branch, where the 1000 BTC has not been spent yet.

Transactions are valid on both branches of the fork.  You send 1000 BTC to a merchant on v0.8 it is seen by the merchant on v0.7 so when you attempt to double spend it is rejected by the merchant and/or every relay node.

The fork was on BLOCKS not transactions.  All the transactions (except coinbase tx which are unspendable for 100 blocks) on the v0.8 branch are visible on v0.7 branch and vice versa.

[piotr_n]

Transactions are valid on both branches of the fork.  You send 1000 BTC to a merchant on v0.8 it is seen by the merchant on v0.7 so when you attempt to double spend it is rejected by the merchant and/or every relay node.

But the real world is not as perfect as it should be.
It's all about statistics and chances - probability.

If you have X connections from your node to the network, and you broadcast transaction A to half of them, while at the same time broadcasting transaction B (spending the same 1000 BTC) to the other half - then you have a significant chance that both; A and B will be mined in the alternate branches. And by "significant chance" I mean: significant enough to cause the panic...

[blockbet.net]

Not sure why everyone is so panicked.

When I have a lot of money invested in Bitcoin and I get an error message and I'm not sure what it means... Well, let's just say that I got a bit worried. Not everybody knows the technical aspects that well. I'm glad they addressed the issues quickly and in a professional manner though.

[taltamir]

So, a regular user who isn't mining should simply have waited a couple of hours and the issue of the fork would be resolved by the network... fine, great...

But what about miners? How is this going to be resolved for miners going forward?
Reddit said that BTCGuild and their ilk have changed back to 0.7, that's great for them but what about people using p2pool? p2pool interfaces with your BC client and as such it would mean everyone with p2pool has to downgrade to 0.7...

Are there plans for a 0.8.1 which resolves this or what?

[Blowfeld]

Even if the problem hadn't been found during testing, if miners had gradually rolled out the change to 0.8 (with a built-in bigger block-size limit), then when the problem cropped up, as long as 51% of the mining power hadn't been on the new "big block 0.8 release", there would not have been a hard fork.

The problem that cropped up is a hard fork, so by definition it would have happened. It's clear now that a hard fork is unavoidable. The only question is when does it happen and who will lose out because of it.

If only a few miners had been on "big block 0.8 release", they could have produced a block the rest of the world didn't understand.  But, wouldn't the rest of the world continued on without that block?  A single orphan block.  I don't exactly consider this a "hard fork".  Am I missing something, here?

The problem was that 51% of the miners were running an essentially untested combination of software and blocksize.  Without manual intervention, the fork that evolved would have continued forever.  *This* is what I call a "hard fork".

Also, I'm afraid it's very easy to say "just test for longer" but the reason we started generating larger blocks is that we ran out of time. We ran out of block space and transactions started stacking up and not confirming (ie, Bitcoin broke for a lot of its users). Rolling back to the smaller blocks simply puts us out of the frying pan and back into the fire.

We will have to roll forward to 0.8 ASAP. There isn't any choice.

The official release of 0.8.0 was just 3 weeks ago:  https://bitcointalk.org/index.php?topic=145184.msg1540252#msg1540252

Unless you are the IT department at Citibank, you cannot possibly expect all of your branches and customers to upgrade on your schedule.  Forcing a tight upgrade schedule on customers and merchants will kill bitcoin as surely as a forked blockchain.  I think LukeJr suggested a 2 year upgrade window.  Seems more reasonable than 3 weeks.  Bitcoin isn't the same as Ubuntu, but look at their support window.

[EuroTrash]

I'm glad they addressed the issues quickly and in a professional manner though.

Doesn't look resolved to me.
The limit is still there.

OK you can configure 0.8 to reject troublesome blocks to make it same as 0.7.

But the limit is still there.
So I guess the devs will have to wait till 0.7 miners are, say, 1% of the network before releasing  a v0.8.1 without the limit. But then the 0.8 miners are being limited by configuration right now. So again the 0.8.1 miners will need to have some sort of logic that makes them wait till they are a large majority, before accepting larger blocks.

(Almost) catch 22? Or where did I get it wrong?

[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.]

Amazing. So you read this entire thread, came away with zero clue as to what happened, and decided to start preaching to the rest of us?

Maybe try reading it again.

Fact:  The official news at the top of the forum (today, 16 hours after the event) says "News: The bug appears to be resolved now. Merchants can accept transactions. Mining on 0.8 is OK, but you should not increase the target block size from the default."

I'm not sure which of my quotes, above, you believe were clueless or preachy.  Do these quotes differ materially from today's official "News".  There was a lot of FUD on this thread.  Much of it was unwarranted.  I thought this part of my post was clarifying the facts, not preaching.

[marcus_of_augustus]

I'm glad they addressed the issues quickly and in a professional manner though.

Doesn't look resolved to me.
The limit is still there.

OK you can configure 0.8 to reject troublesome blocks to make it same as 0.7.

But the limit is still there.
So I guess the devs will have to wait till 0.7 miners are, say, 1% of the network before releasing  a v0.8.1 without the limit. But then the 0.8 miners are being limited by configuration right now. So again the 0.8.1 miners will need to have some sort of logic that makes them wait till they are a large majority, before accepting larger blocks.

Pre-0.8 nodes can up their limit voluntarily via Berkeley DB config file settings, so there does not have to be this rush to upgrade, or rush for the exits ....

https://bitcointalk.org/index.php?topic=152208.msg1615346#msg1615346

There just needs to be a consensus (and enforcement) on what those limits need to be set at instead of this "default" behaviour (implicit network rule).

Edit:

http://www.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/lock/max.html

This link is for you Mike H. ^^

[The-Real-Link]

Thanks for the insight and taking care of things so swiftly. 

[SgtSpike]

I'm glad they addressed the issues quickly and in a professional manner though.

Doesn't look resolved to me.
The limit is still there.

OK you can configure 0.8 to reject troublesome blocks to make it same as 0.7.

But the limit is still there.
So I guess the devs will have to wait till 0.7 miners are, say, 1% of the network before releasing  a v0.8.1 without the limit. But then the 0.8 miners are being limited by configuration right now. So again the 0.8.1 miners will need to have some sort of logic that makes them wait till they are a large majority, before accepting larger blocks.

(Almost) catch 22? Or where did I get it wrong?

I would think every Bitcoin user running a full node would also have to upgrade, else they would receive errors and not be able to download/process/verify the latest blocks as well?  It's kind of a forced upgrade once the miners make the switch, since the pre-0.8.1 users wouldn't have very many (if any) new blocks generated on their fork.

[notme]

IN 3 hours the price of bitcoins will be around 14 bucks. Mark my words

Words marked.  I hope you didn't trade on your own advice .

[evilpete]

Even if the problem hadn't been found during testing, if miners had gradually rolled out the change to 0.8 (with a built-in bigger block-size limit), then when the problem cropped up, as long as 51% of the mining power hadn't been on the new "big block 0.8 release", there would not have been a hard fork.

The problem that cropped up is a hard fork, so by definition it would have happened. It's clear now that a hard fork is unavoidable. The only question is when does it happen and who will lose out because of it.

If only a few miners had been on "big block 0.8 release", they could have produced a block the rest of the world didn't understand.  But, wouldn't the rest of the world continued on without that block?  A single orphan block.  I don't exactly consider this a "hard fork".  Am I missing something, here?

The problem was that 51% of the miners were running an essentially untested combination of software and blocksize.  Without manual intervention, the fork that evolved would have continued forever.  *This* is what I call a "hard fork".

It's not that simple  More than 51% of the miners were running 0.8.  One single pool with a large block size created a valid block that all 0.8's accepted.  All the 0.7 miners and users rejected it due to the lock table overflow.

I don't believe this can happen again because >51% of miners are now on 0.7.  Even if a solo 0.8 miner recreates a block that causes 0.7 to freak out on,  it will find itself automatically orphaned.

Last night slush's pool was running 0.8 with the large txn blacklisted in order to get back onto the 0.7 chain.  That helped converge the chains but doesn't count towards the ongoing "> 51% on 0.7" goal - it would have accepted a "new" 0.7-breaker txn as valid and contributed to that fork.

[dree12]

Even if the problem hadn't been found during testing, if miners had gradually rolled out the change to 0.8 (with a built-in bigger block-size limit), then when the problem cropped up, as long as 51% of the mining power hadn't been on the new "big block 0.8 release", there would not have been a hard fork.

The problem that cropped up is a hard fork, so by definition it would have happened. It's clear now that a hard fork is unavoidable. The only question is when does it happen and who will lose out because of it.

If only a few miners had been on "big block 0.8 release", they could have produced a block the rest of the world didn't understand.  But, wouldn't the rest of the world continued on without that block?  A single orphan block.  I don't exactly consider this a "hard fork".  Am I missing something, here?

The problem was that 51% of the miners were running an essentially untested combination of software and blocksize.  Without manual intervention, the fork that evolved would have continued forever.  *This* is what I call a "hard fork".

It's not that simple  More than 51% of the miners were running 0.8.  One single pool with a large block size created a valid block that all 0.8's accepted.  All the 0.7 miners and users rejected it due to the lock table overflow.

I don't believe this can happen again because >51% of miners are now on 0.7.  Even if a solo 0.8 miner recreates a block that causes 0.7 to freak out on,  it will find itself automatically orphaned.

Last night slush's pool was running 0.8 with the large txn blacklisted in order to get back onto the 0.7 chain.  That helped converge the chains but doesn't count towards the ongoing "> 51% on 0.7" goal - it would have accepted a "new" 0.7-breaker txn as valid and contributed to that fork.

If no miners mined on 0.7, the users would not get any confirmations on their fork and would upgrade as soon as they noticed, without loss of money. The problem lies in how there were significant numbers of miners on older versions, and those would be exactly those that would be hard to reach and encourage to upgrade.

[Mysticsam_3579]

Have anyone even thought about if bitcoin was worldwide when this happened?

Good luck asking the stock exchanges in Tokyo and London to stop processing deposits and withdraws!
Or a little market in Russia to wait for making its sales.

Think if this had lasted i couple of days?

[pwrgeek]

Not sure why everyone is so panicked.  We only orphaned 25 blocks and the only danger was that you would accept the coins minted in those blocks (all transactions using other coins would eventually end up in the other chain as well).  If we just followed the network rules and waited 100 blocks to accept minted coins then there was actually no danger at all.  What am I missing? 

You are missing the fact that it was a great opportunity to double spend any coins.
Once: you send 1000 BTC paying to merchant that uses bitcoin 0.8
Second: you pay the same 1000 BTC to another merchant who has an older client and thus is "looking" at the alternate branch, where the 1000 BTC has not been spent yet.

Anyone not waiting for multiple confirmations and not listening on the network for double spend attempts on transactions this large deserves what they get.

[Luke-Jr]

[nebulus]

Am I fine using the 0.8 to transact and is something this sort likely to happen in the future? Thanks!