On Sun, May 31, 2015 at 1:29 AM, Matt Whitlock <bip@mattwhitlock.name> wrote:

3. What *is* clear at this point is that Gavin will move ahead with his proposal, regardless of whether the remainder of the Bitcoin Core committers agree with him. If he has to commit his changes to Bitcoin XT and then rally the miners to switch, then that's what he'll do. He believes that he is working in the best interests of Bitcoin (as I would hope we all do), and so I do not fault him for his intentions. However, I think his proposal is too risky.

I seriously doubt if miners and merchants who's income depends on bitcoin are going to risk a network split. Gavin isn't pedalling some mempool policy which doesn't affect consensus. The changes have to be universally adopted by miners and full nodes. If there is any uncertainty about that global acceptance, those financially dependent on bitcoin will not take the risk just to be political. You can see how conservative the mining community is already by their slow upgrade of Bitcoin Core as it is. Even if some miners and merchants generally support the idea of bigger blocks, they most certainly are not going to take the risk of leading a hard fork when there is substantial risk of it failing.

Until there is actual consensus among the technical community I wouldn't be too concerned.

4. I also think that ignoring the immediate problem is too risky. If allowing significantly larger blocks will cause a serious problem for Bitcoin (which is a possibility that we cannot rule out, as we lack omniscience), then NOT making any change to Bitcoin Core will virtually *assure* that we cause exactly this problem, as the popular (non-technical) consensus appears to be in favor of Bitcoin XT and a larger block size limit. If we do nothing, then there's a very real chance that Bitcoin XT takes over, for better or worse.

I don't think anyone is ignoring the issues, nor that everyone accepts that blocksize may have to eventually change. The overwhelming technical majority do not agree there is a problem that needs to be immediately addressed. It would be far more helpful if we focused on stuff that helps enable level 2 technologies so that bitcoin can actually scale, (like R/CLTV and malleability fixes which are being delayed by BIP66 rollout and pending the new "concurrent soft-forks" proposal).

7. It's not a given that blocks will immediately expand to meet the hard limit. In fact, there are strong and compelling arguments why this will NOT happen. But in any software system, if a given scenario is *possible*, then one MUST assume that it will happen and must have a plan to handle it.

But of course it would be dealt with if and when it becomes necessary. It's not like there is blanket opposition to increasing the blocksize ever, it's the matter of if, when and how; but when is defintely not now.

9. My proposal is that we raise the block size limit *gradually*, using an approximately smooth function, without a step discontinuity. We can employ a linear growth function to adjust the block size limit *smoothly* from 1 MB to 20 MB over the course of several years, beginning next March.

Automatic or dynamic blocksize increase risks being very difficult to shut down if later we find it is negatively impacting the ecosystem... and that's part of the reluctance with bigger blocks because we still have not studied the potential downsides enough beyond some sketchy and disputed calculations and overall it's not addressing scalability at all.

10. This is the difference between cannonballing into the deep end of the pool and walking gingerly down the steps into the shallow end. Both get you to the eventual goal, but one is reckless while the other is measured and deliberate. If there's a problem that larger blocks will enable, then I'd prefer to see the problem crop up gradually rather than all at once. If it's gradual, then we'll have time to discuss and fix it without panicking.

Extending blocksize now would be nothing more than a political move. I have no idea what will be decided in the end, but I do know that in order for bitcoin to survive, changes must be based on well thought out and discussed technical merits and not the result of political pressure. Politics and good software do not mix.

Drak