[...]
I think we mostly agree--it should be difficult to actually change the consensus layer because we should all be in tight agreement about what's in that layer. And we are in agreement!: we all agree that double spending is bad, we all agree that valid signatures should be required to spend coins, and we all agree that Bob shouldn't be able to create coins out of thin air. In other words, we already agree on what constitutes valid transactions.
But we don't agree on the block size limit. That's OK, though, because we don't actually need to view the block size limit as part of the consensus layer. The block size limit doesn't affect what transactions are valid.
So I suggest we agree to disagree on the block size limit. Let's move the limit from the consensus layer into the transport layer instead, and give all node operators the ability to very easily adjust it. If we do this, then we don't even need to worry about figuring out the "perfect way to adjust the block size"; it will evolve naturally in a decentralized fashion.
What do you think?
[...]
Hey Peter, I am in the process of writing a draft of what might become a BIP, hopefully can push something (very early & incomplete) to github soon to serve as a start on this. While further thinking about the whole blocksize mess, I had the following idea and I do not know whether it has been discussed yet:
The intend is to make the block size limit (BSL) configurable, command line or edit box, with eventually no default. The next step along this line would be - when thinking about BSL as an agreement that must be reached through communication of all interested parties - to have a BSL that can be dynamically and on-line set from outside the Bitcoin core software with something like a 'BSL governor', for example through a secured JSON-RPC call 'setmaxblocksizelimit'. Such as an external program that weights the input of several miners through their twitter feeds for example (not that twitter would be particularly good way to do it), or someone else might implement a scaling limit depending on a moving average or even anything noone even thinks of right now.
Now, what I noticed is that, to some extend, the hard fork/no hard fork split is a false dichotomy: Esentially, we have chain splits all the time in the way of orphans. An enduring chain split will only happen if people value two chains, or at least the survival of 'their' chain more than having a common agreement and single money system. (This is, by the way, a core incentive in Bitcoin, as laid out by Satoshi back then.)
Now, with 'BSL governors', there would be no need to make this a hard decision 'orphan/no orphan this block because I dislike the size of a block in this chain'.
Instead, a full node could make its decision softer: Its BSL governor could for example look at the hash power longest chain, and say: I'll limit blocksize to 1MB when there is no hash power longest chain with more than 5 blocks (or any other figure) ahead of the 1MB one I am on.
This way, the full node would create a disincentive for miners to make bigger blocks, while still allowing it should the need for a larger blocksize be strong enough. Miners will have an incentive to tread carefully, dipping their toes, for example with 1.1MB blocks first, and full nodes can weight their needs by choosing a trade-off between influence on miners and their local chain reorg risk. This would make what you call a 'gray limit' and I think is very *visible* to the user and also *flexible*.
Thoughts?