It only takes 51% of the hashing power to decide which is the next valid block. So the "certain configurations" above can find themselves in the minority; too bad for them. This is the way it has to work.

No. I was not aware of the split in hashing power. Personally, I agree 100% that they should have pressed on with v0.8, with that knowledge. However, as I am not involved in the dev sphere, then I am going to defer to their collective judgement on the best course of action, which was to revert.

If they did that, all 0.7 clients would have been left dead in the water, unable to rejoin the main chain and forcing end users to upgrade on the spot. 0.8 clients can rejoin the 0.7 chain so this was why it was preferred.

I'm not sure. The only way to resolve this was to force *all* 0.7 users to upgrade. Here only 2 pool ops (slush and Eleuthria) could single-handedly put the 0.7 hashrate ahead by downgrading their bitcoind nodes which will solve the problem for everybody in the following hours.

Plus there was no risk in downgrading but given enough time eventually all 0.7 users would be vulnerable to a nasty and no hashpower double spend attack.  That would have created chaos, confusion, and damaged the credibility of the network.

Maybe the alert system should be used to force client upgrades, it is abit draconian but we can't risk the whole premise and validity of bitcoin because some people are slow to upgrade, Am I right in thinking that if everyone had upgraded straight away this wouldnt have happened?  People are always free to create there own alt coin with the bitcoin source are they not?

This though risks the communities decision to decide what changes in the client software they accept and implement, but it secures the collective currency. do everybodies funds would be safe untill they moved or converted them to an alt coin or differing implementation of bitcoin. I think we have risks of both a hard fork and soft fork when we should only have to worry about one if I understand the hard soft analogies properly.


Is it true that the Satoshi dice filtering script is could be the cause of this?

If the bug in the 0.7 clients is creating blocks that are too large or broken for other 0.7 clients then why have we been advised to downgrade, if 0.8 clients can accept these blocks (from the bugged out 0.7 clients) Then wouldn't a better idea have been to urge everyone to upgrade to 0.8 and issue an alert to clients telling them if they do not upgrade they may not be able to spend there bitcoin? or are there other factos at play?
As it stands it looks like the bug affecting 0.7 could still appear only with no tolerant 0.8 clients around??


please help me understand.


I think the devs should be using extensive use of stickies and polls before updates that change the block limit and extensive announcements should be made about upcoming upgrades and there benefits.

I'd like to see this mess fixed and a swift move to 8.01 with the 1mb hard limit removed, if this will result in faster confirm times, less satoshi dice ridiculessness and hope that the whole thing won't come crashing down after we get to some "limit". although i still don't fully understand the implications of the block size restriction I am going to digg up the thread discussing it.

Worst idea in the last 24 hours.  That is pretty amazing given the pretty much nonstop run of bad ideas.  There will not and should not EVER be a forced upgrade option for Bitcoin.  Not today, not tomorrow, not a century from now.  Your idea would be a "kill bitcoin" button available to anyone with the resources (either financial or through use of force) to push it.

That's not quite right D&T because we already have a forced upgrade situation imminent!

http://blockorigin.pfoe.be/top.php

When the percentage at the bottom of that screen goes from 78% to 95% then 5% of the hashing power is forced to upgrade or cast adrift.
However, IMHO, this is the only way Bitcoin can progress from a crypto-experiment to a world-beating currency and payments system.

That's why I said "not quite right" rather than flatly refute. There are a lot of perspectives to the argument.
Of course I reject forced changes of software as you (and whitenight) describe.