Quote from: gmaxwell on June 15, 2015, 12:35:55 AM

...in fact, both SC and LN _strongly_ prefer the biggest blocksize the network can handle. What they can't tolerate, however, is Bitcoin being very centralized-- and I don't think your own interests can tolerate that either (assuming you still own some Bitcoin).

reddit post

Quote

The experience we have says there will not likely be a dire emergency. We also have reason to believe, from the prior accidental quasi-hardfork, that the mining portion of the network can be updated within a day or two during an actual emergency. A straight-forward blocksize bump also has the benefit of being completely compatible with existing SPV clients (they can't see the blocksize). If there really were a dire situation where it was larger blocks or doom-- I'm confident that larger blocks could be deployed quickly without much trouble; and in that kind of situation: consensus would be easy. No matter how concerned people are about larger sizes, if the choice is really larger or a useless network, the former is preferable to everyone. There is also plenty of room for other creativity, as we saw before in 2013, should the need arise, but it can be hard to predict in advance.

(my emphasis)

Greg is giving me serious cognitive dissonance with these posts.
He is very concerned about the trend to centralization and yet can countenance a quick fork if necessary.

The most harmless hard fork is one which is prepared so far in advance that all software instances are upgraded before it takes effect. Something which was almost achievable if it had been scheduled in early 2013 with the target date about 2 years ahead. That is what Bitcoin needed.

Today, the time for this luxury is gone and about 6000 nodes exist (which accept connections). The worst scenario after a quick fork is 3000 left on each side, with the best scenario somewhere between 3000 and 6000 on the majority side, say 4500 nodes upgrading. The remainder either switching off or flailing away on a chain with a ridiculous difficulty. What a hammer-blow towards the furnace of centralization!

In my opinion, the odds of a dire situation after the 1MB is hit, needing a quick fork, is about 99%. This not an unreasonable interpretation of the separate findings of David Hudson and Statoshi. Even if Greg thinks the odds of needing a fast fork is more like 10% or 20% (otherwise why describe it in the manner above) then this is surely an unacceptable risk.

Meanwhile, Adam has just given us a Hallelujah moment:

Quote

A hard-fork takes a long period of time to deploy due to the non-upgrade risk, people are working on things in the mean-time.
There can be a case for some increase to create some breathing room to work on scaling and decentralising tech, I just mean to say that if we do it in isolation, we're not focussing on the big picture.

Progress at last, buying time to smoothly scale the MC, as well as buying time for SC and LN. FFS! How can this be contentious to SC and LN supporters?

Lastly.
Perhaps Peter R can put this one to bed:

Adam claims that the network overhead in scaling Bitcoin is O(n^2), where n=transactions
Mike counters that it is O(nm), where m=nodes

The latter makes more sense to me, and further, that m is not as significant as it appears because it is highly parallelized.