Topic: Alert: chain fork caused by pre-0.8 clients dealing badly with large blocks - page 11. (Read 155551 times)

The protocol whould have dealt with that situation just fine even if there was no "handling". Just in that case, we had gotten a (temporary) fork, not just some orphaned blocks, and this might have created more confusion. So the system was safe during that incident anyway, but the action taken by some community members helped to resolve it with the least hassle.

I would like to ask this question as well.

Thread should be closed.

+1

Is this thread sufficiently old and boring that I can now start trolling it with pictures?

And the immediate willingness of people to cooperate when it matters.

Imho a "decentralized currency" shouldn't need handling from anyone.

I still don't understand what the issue was, but I'll formulate my question exactly at a later time. I (thought I) understand how the block chain works, it's not that the posts are too technical or anything, but I'll ask later.

Well said. Whatever the short-term fallout, this gives me *more* confidence in the long-term robustness, both in terms of system design (in that issues *can* be resolved quickly without much user impact), and also in the community to quickly arrive at consensus and execute the best solution.

Bitcoin will no doubt run into issues in the future, ranging from similar issues to outright attacks, and I like seeing this fire drill handled so effectively.

It's interesting to see the two different sides of this debate. Is 0.8 the problem because it doesn't conform to the established rules of the system or are the older clients the problem because they use a crappy database which can't handle large blocks?

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.

Obviously this was the best solution to apply and I'm glad the hard fork route was not taken. Such a route needs to be properly planned and even then it will be difficult to coordinate a change such as an increase in the max block size.

But do we really need to increase the max size of blocks? I don't know all the technical details behind bitcoin, but it seems to me that if 1 block is being saved into the blockchain every 10 minutes then the max size should be limited to something relatively small.

If we would treat our credit crisis in the regular markets like this, the crisis of 2008 would already have been forgotten (except for the losers).

Well said.

Can you imagine how some large bank would have handled this? A bunch of press conferences, perception management, BS, lies, you name it.

Sure, it looks ugly when the gritty details are thrown out there and people get scared, misunderstand what's going on, etc. but that's the price of transparency.

We can handle a few inconveniences (don't use bitcoin for a couple hours, etc.) as long as we are allowed to know what the heck's going on.

It's not much to ask for, really, but if you think about it who besides Bitcoin gives that to us?

Keep your software updated.

Bitcoin stays protected. Nothing could actually happen. If an attack was made, the algorithm would be changed.
If something like this happens, it fixes.

Gentlemen, you just watched finance in the 21st century.

*complete transparency
*community driven
*solution driven
*results

Bitcoin just gained a lot more confidence.

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.

Along with raising the size limit, I have also been strongly urging people to upgrade to 0.8 for some time now. In fact, I'm the one who originally benchmarked and wrote the code to use LevelDB - the mysterious problems we've had with bdb being one of my motivations (the other was performance).

Ultimately, this problem is an old bug that has already been resolved through a large effort to get us off bdb. It's unfortunate that so many miners have NOT heeded the call to upgrade and we had to learn another one of bdbs inadequacies the hard way, along with rolling back to keep those slow miners online. Every miner will have to upgrade sooner or later, that is just inevitable.

Atlas's post was not prescient or insightful. We knew when we made the switch to LevelDB that it introduced the risk of a hard fork. This is not something that had to be pointed out by a banned forum poster. However - as you can see - there was no alternative. BDB has serious, fundamental problems that cannot be fixed. Upgrading to LevelDB is the solution.

Remarkable! And see how Atlas was attacked for his posting, which has now turned out to be right on target.

Well the fact that it was solved so fast seems to imply that the system is pretty robust.

Why thankyou, that's exactly what I'd like to do to your words at this juncture.

Well. There's still 90 minutes left. But I think you'll probably still be an idiot in 90 minutes.

Simplifying a bit:

Bitcoin works at two levels.  There's a peer-to-peer network that floods instant transactions from node to node.  These are sanity checked and redistributed to the other peers that haven't seen it yet.  They're fast but are only kept in memory.

Miners do the number crunching to form blocks.  Blocks form the permanent records.  These blocks are also distributed over the peer-to-peer network and are integrated into the permanent database.  Miners are paid by the network itself for doing this.  Miners do extensive validation and permanently record the transactions above.

If two miners both try to produce a block at the exact same time, only one can survive.  The "fast" transactions are recorded in both blocks so nothing's lost.  However, the losing miner doesn't get paid.

What happened tonight is a minority (but significant) number of miners and end users with <= 0.7 rejected a large but valid block and then went off on their own fork.

There were two solutions to this, either:
1) Everyone must upgrade to 0.8+.  Everyone.  (Or upgrade to a fixed 0.7, 0.6, 0.3 etc and reindex)
2) Move enough of the 0.8 miners to the 0.7 blockchain fork and cause the network to reorganize.  That makes everyone converge on the same chain again.

The upshot is that the miners of the previously winning fork gave up all their miner fees for the good of the community in order to get everyone back on the same page.

  all good here also.Coins finally confirmed.

Just synched my 0.7.0 client (to the latest block height) and there is no longer any DB error displayed.  I again see a green bar, the blocks downloaded and the checkmark is good.

All appears to be in order.