Topic: #Blocksize Survey - page 17. (Read 16144 times)

Of course the devs don't have the final word... many other stakeholders will get to vote on what actually happens, especially in a hard fork where any holder of BTC will get to choose sides. Miners, nodes, wallet providers, investors... all will have their say.

Still, a broad consensus is very desirable as a contested hard fork will cause a great deal of turmoil. A 50-50 Bitcoin civil war would be a horrible scenario, causing volatility and uncertainty for many months or even years.

With a bit of leadership and consensus among developers, it should be much easier to reach a meaningful (90%?) consensus in the Bitcoin community which makes the hard fork as smooth as possible.

For near-term increase:
Gavin Andresen: Currently favors "8MB very soon, then automatic double every two years till it hits 8GB in distant future", aka BIP101. Also finds Jeff Garzik's BIP100 (see below) acceptable.
[INTERVIEW] https://youtu.be/B8l11q9hsJM
Mike Hearn: Agrees with Gavin on BIP101. Currently working on implementing the increase in an alternative client, Bitcoin XT, to provide full node operators with a real choice.  
[INTERVIEW]  https://youtu.be/8JmvkyQyD8w
Jeff Garzik: Favors "8MB after miner negotiation and a delay period before enforcement, stepping up/down on maxblocksize possible after with similar miner voting, absolute upper limit for the hard fork at 32MB", aka BIP100. Also proposed "2MB immediately and nothing further", aka BIP102, as an emergency stopgap in case adoption takes off, fees ratchet up and the sudden ecosystem meltdown puts further growth in danger.

For very conservative increase:
Pieter Wuille: "First increase scheduled at 2017 (to ~1.04MB, I believe), then automatic increase some 17% per year till 2GB in distant future", aka "Draft BIP103" (nominally un-numbered).
Luke-jr: Finds Pieter's proposal an acceptable compromise, though generally favors smaller blocks, occasionally expressing views that even 1MB blocks are too big.

Against increase until "something X is implemented":
Adam Back: Proposed "Extension blocks", aka a sidechain-lite, that allows migration to bigger blocks with only a soft fork. Also favors only migrating when sidechain tech is ready, against hard-forks in general.
[PODCAST] http://a16z.com/2015/09/02/a16z-podcast-hard-forks-hard-choices-for-bitcoin/  [VID] https://youtu.be/wYHyR2E5Pic

Against increase in near-to-medium term future:
Gregory Maxwell: Against hard-forks in general, also against bigger blocks in the short-to-medium term future.
Mark Friedenbach: Against hard-forks in general, also against bigger blocks in the short-to-medium term future.

Staying neutral:
Wladimir J. van der Lann (Core lead dev): "You guys wake me up when you have a consensus, not gonna merge anything till then" (not actual words)