Since most people mine as part of pools these days, it probably doesn't matter too much. The average rate for the pool won't be affected too much (though I suppose pools which have been on the 0.8 block chain will hurt a little bit). There may be a one or two individuals who have mined a block and lose out by this, but if so, they were rolling the dice anyhow by mining outside of a pool; you can't expect a consistent income by mining over a span of 13 blocks.

If you are solo-mining and you found a block on the 0.8 branch of the fork, the standard client prevents spending newly minted coin with less than 120 confirmations. It will be the same as what happens when you get any other orphaned block, the funds will just disappear.

In the grand scheme of things, how much control over bitcoin do the developers have? My understanding of bitcoin is that there is no central authority controlling it like a central bank, but this statement almost implies that the developers have some kind of control, or influence at least, over bitcoin.

The bankers were playing with other people's money, not their own.

This assumption that people always work for the long-term gain, even for themselves, was proven wrong in the financial crisis. The economy is made up of humans, and humans make mistakes.

Later, you bring up the point of $100 million paid to the Lehman Brothers executives. Do you know how much they got every year ? These guys are paid $50 million / year or $30 million / year PLUS stock options... if they wanted to make more money, they should have kept Lehman Brothers operating for just 3 more years.

If the majority of people decided they didnt like the current rules (eg all the people complaining about bitcoin deflation) they could very well change them by simple agreement.

One can't simply force a change to the rules. All you can do is make a hard fork in the network. If nobody adopts your hard fork well you can keep mining worthless coins but people can continue to use/mine the existing fork.

Bitcoin is highly resistant to change (almost to a fault). It is a common myth that the person who controls the majority of hashing power can change the rules.

Of course, this is only possible becuase your chain looks as if it was following the rules. If you have a non malicious computational majority, than any change in the rules would make an incompatible block-chain and a hardfork.

The collective "authority" decides how the bugs are to be addressed. Bitcoin is not fully autonomous and without social guidance.

As far as I can tell this sort of centralisation of influence is a common emergent property in most anarchic human systems.

Luckily if something particularly egregious occurs in this case, the community can easily fork the codebase and start a rival blockchain.

http://catb.org/esr/writings/homesteading/homesteading/

Even once that happens, if there are more 0.7 clients than 0.8 clients, they will keep mining, eventually generating a longer chain, and the 0.8 clients will start accepting that longer chain. It's only once 0.8 has more mining power behind it that you get a split; now the 0.8 clients will keep forming a longer chain, and the 0.7 clients will be left behind, as they still see that chain as invalid (due to the invalid block), so they only see the 0.7 chain.

So, while the 0.8 clients were not "wrong" in accepting the bad block, it's pretty hard to fix the problem by convincing everyone to update to 0.8; some people may just not be able to or want to update. But it is easier to fix the problem by getting just enough people to downgrade to 0.7; as long as more than 50% of the mining power is on 0.7, that block chain will be the longest and both 0.7 and 0.8 will work fine with it.

Another way to look at it is to ignore the spec, and just look at the reality of implementation. According to the reality, 0.8 introduced a non-backwards-compatible feature allowing it to accept new kinds o blocks. In terms of protocols, this is sometimes known as "embrace and extend"; support the open protocol that everyone else supports, but add extra incompatible features. While this probably wasn't intended, the effect was that 0.8 miners got an advantage on mining new blocks; they would accept block mined by 0.7 miners, thus keeping ahead of the chain, but once they managed to mine an incompatible block, they would now be a block ahead of the 0.7 miners.

Now, what does this mean in terms of transaction security? Most likely nothing, unless there were any double spends, where the same coins were spent in one way on one chain and another way on the other. If there were double spends, you could look at both block chains and find them; given how quickly this was caught, it's pretty likely you could track down where the double spends went, and it's unlikely that the double spends have changed hands more than once given how short this split is. But there are other factors that make the double spends unlikely. Most transactions will propagate throughout the network pretty quickly, to miners on both sides of the block chain split, meaning that both block chains are likely to record the same transactions. You would have to notice this split, and target transactions at each side of the split so that miners on each side would pick up separate transactions, without the person that you are sending the coins to (and who is presumably sending you something else in return) noticing, all within the span of a few hours.

Now, given that this has happened once, I would be surprised if someone doesn't write a bot that noticed this kind of split and do just that, to see if they can get any double transactions accepted. To defend against this, anyone who cares that much (such as any large Bitcoin merchants or payment processors) can do the converse, monitoring for any chain splits and following both sides to watch for double payments, treating those as fraud and returning (or keeping) them without actually delivering the goods in question.

Unfortunately the limit that was hit (which isn't quite as simple as 'size') was implicit in BDB and how Bitcoin prior to 0.8 used BDB. So no one was aware of it.

Extensive testing during 0.8 turned up several consensus breaking issues that were created during the database switch out, and very large blocks were tested... but the particular kind of very large block required to reveal this difference in behavior was not.

Everyone followed proper behaviors, it's just a compatibility problem. So miners should resort to 0.7 until 0.8 can prevent a fork like this from happening again.

They do not need everyone to stop using 0.8, just a majority (so that the 0.7 chain becomes the strongest).

You would need to get everyone to stop using 0.7 (or much more than a majority, or as soon as another block of this kind resurfaces the clients would be useless again).

0.8 accepts blocks that 0.7 rejects, 0.8 does not reject any blocks that 0.7 accepts. So 0.7 is more compatible going forward until the problem is solved with 0.9 etc.

This is a quick fix to get the system back on its feet while they figure out the longer term strategic answer.

A second thing that I don't understand is why 0.8 people are vulnerable to double-spending attacks. It wasn't said that 0.7 was safe, but it was said that 0.8 was vulnerable. But with two separate blockchains, wouldn't both be vulnerable? Or at least 0.7 because they don't accept 0.8's blockchain?

Upgrading: Those who doesn't upgrade end up with their own chain.

Downgrading: Those who doesn't downgrade will automatically use the other chain when it becomes dominant.

> But with two separate blockchains, wouldn't both be vulnerable?

It's only the chain that doesn't become the main chain that is vulnerable. Because they're pushing for 0.7 to be the main chain you don't have to worry about double spending there.

They don't (can't) rule with an iron fist, but they have a lot of good will with the community, so most will listen to them.

EDIT- The good/bad news is that since most mining (and thus transaction verification) has consolidated into large pools of machines, only a few people have to agree with "them". So in a sense, there is a central committee of people who run the large mining pools that does have a fair amount of power.

Even though the pool operators have large discretion, the computational power that makes up their pools can be moved elsewhere... a little like a transferable proxy. Most smaller miners probably trust the pools who they've grown confident in... but a large enough controversy or campaign could conceivably shift the mining-power away from pool operators who make unpopular decisions.

Open source works the same way. Of course there are authorities for a given project who can choose what the final release is, but if they get too full of themselves or something it's easy enough to bypass them. It's happened quite frequently, so it's not an idle threat, either. You can't prevent authority from developing, that's wouldn't even be a good thing, but you can prevent it from abusing its current position of authority to lock in future authority.