"By expecting a few developers to make controversial decisions you are breaking the expectations, as well as making life dangerous for those developers. I'll jump ship before being forced to merge an even remotely controversial hard fork." Wladimir J. van der Laan

Everyone wants Bitcoin to succeed, and to scale.

Believe me, not everyone wants to see bitcoin succeed, and to scale.

Some examples? Anyone holding large quantities of RippleTM or Lite Coin stand to profit handsomely if bitcoin fails. Holders of privacy centric alt-coins stand to profit immensely if there is a regulatory crack down on bitcoin. If the Fed partners with IBM to create FedCoinTM , all banks, IBM, and anyone partnering with them to provide services would like bitcoin to be seen as an "interesting experiment" that's relegated to history in a manner similar to Usenet or Compuserve.

More examples? Anyone promoting a non-merge mined sidechain scheme would love for bitcoin to fail after they are up and running, as they are a "safety valve" where money can flee.

Furthermore, anyone who took large quantities of money from VC companies and is trying to deliver on side chains or similar schemes would not want to see bitcoin outright fail, but they would love to see it fail to scale effectively, as this validates their VC backer's vision that sidechains are necessary for bitcoin to grow and go mainstream.

I could go on, but I'll just stop here. I get the feeling you may know a good bit of this on some level anyway...

The question is when and how, and is it a good idea to set precedent for political hard forks against the wishes of the maintainers of the project.

I think this was sufficiently refuted as excessively optimistic above.

And do you also give a pass to "Bitcoin 2.0" companies? They live and die in the nether regions of blockspace, and need fees to be as small as possible to efficiently inject arbitrary data.

When you speak of the "blockspace" are you talking about OP_RETURN outputs? Open assets / colored coins and similar schemes use OP_RETURN and would love another OP_RETURN field and low transaction fees, but they are by no means the only "2.0" companies out there. Some are not much more than white papers and require changes to bitcoin beyond OP_RETURN to function. Others (also whitepapers) require looping between scripts for the most part, which is a hard fork to bitcoin - unless the blockstream folks have solved for this challenge somehow (not sure how they would).

What about the likes of BlockCypher and Chain.com, and other startups that make cash the harder it is to run a full node?

They have a vested interest in seeing SPV clients used more ubiquitously, but their primary focus will be business partnerships with banks and hosted wallet providers. I would see them in favor of more aggressive cap increases, but that might be OK. The cap was never intended to keep bitcoin blocks small so full nodes would always be viable. It was put in place to prevent transaction spam, and economics grew up around it. That said, I'm a believer that amateurs should ALWAYS be able to run full nodes if they so choose, because I believe centralization of full nodes is not good for the health and distributed nature of bitcoin. When I say "health of bitcoin" I'm not being vague, I mean health to be the the price of bitcoin trading on exchanges in other currencies. 8MB scaling x2 every 2 years keeps growth under the curves of broadband, storage, and processing cost efficiencies long term, and accomplishes this goal.

This isn't just about sidechains and altcoins, there's a huge amount of VC funds riding on colored coins and blockchain API services.

Yes, I'm well aware. It's important to be aware of who works for what company when evaluating what solutions are proposed.

You're also forgetting MultiBit, which is extracting a 1000 Satoshi fee per transaction. Or the numerous open source wallets now working with multisig providers which charge a fee to unlock funds. Tons of different angles make the block size debate full of holes and vested interest.

I've clearly demonstrated that not everyone wants bitcoin to succeed, and that some benefit from it failing. I've clearly demonstrated that some benefit from bitcoin stagnating, because it validates the need for their 2.0 approaches. Throwing various bitcoin wallet and service providers like multibit and chain.com into the discussion does nothing but muddy the water and create a needless delay in a solution.

I stand by my original statement. The solution that's best for bitcoin, as determined by "would it increase the price of bitcoin in other currencies" should drive the solution, and ultimately it will.

I believe that solution will be a simple increase of the max block size, increasing at a set rate every N blocks. There's a possibility of a second moving average type cap to create fee pressure. The former and perhaps the later are solid if done well. Voting is another possibility, but there are a lot of "gotchas" in BIP-100 as proposed. They would need to make it "increase only" and use a default value that scales so lazy miners don't hardcode caps into their votes.

/r/Bitcoin Thread Parent Link - lists.linuxfoundation.org