> I just wish that half as much energy had gone into discussing > whether we want a 100% supermajority or a 99% supermajority or an > 80% supermajority, as has gone into discussing whether we want 1MB > blocks or 8MB blocks or 20MB blocks.
And I understand that Gavin is now proposing that a 75% supermajority should be enough. This constantly reducing threshold worries me greatly. There is a risk that we get a situation where a stable amount of hashing power somewhat over 75% (say 80%) accepts the fork - and therefore triggers it - but both a significant minority (say 20%) of hashrate rejects it *and* the economic majority rejects it. I'm not saying this is a likely outcome - indeed I hope it's not - but it is a _possible_ outcome. Ok, the chain that the economic marjority is using will have a bit of a temporary crisis due to 50 minute block times, but it will recover in a few weeks as difficulty adjusts. And, in the worst case, you end up with two competing semi-stable ecosystems both claiming to be 'the real Bitcoin'. My fear is that in that situation it could take an extended period - perhaps many months - for one fork to clearly win and the other fork to lose support (or at least lose sufficient support to be relegated to altcoin status). I think such an extended period of uncertainty would be the ultimate worst case scenario for Bitcoin. It _probably_ wouldn't be fatal to Bitcoin, but it would certainly be far worse for Bitcoin than getting the blocksize wrong even by an order of magnitude (in either direction). Therefore if we can design the hardfork mechanism to make such an outcome impossible, I believe we really need to. roy ------------------------------------------------------------------------------ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
