Quote from: adam3us on January 02, 2016, 05:58:17 PM

The proposal seems at first skim to be a copy of a few existing technologies from Bitcoin's roadmap and were first proposed by Greg Maxwell and others*: weak-blocks & network-compression/IBLT to reduce orphan risk, and flexcap (or a variant of it perhaps).

That is something else, perhaps from one of the research papers on future areas of interest.

Bitcoin Unlimited's main change at present is simply that, for better or worse, it makes it more convenient for miners and nodes to adjust the blocksize cap settings. This is done through a GUI menu, meaning users don't have to mod the Core code themselves like some do now. Planned improvements to BU include options that automatically mimic the blocksize settings of some Core BIPs, as well as blocksize proposals recommended by other luminaries.

The idea is that users would converge on a consensus Schelling point through various communication channels because of the overwhelming economic incentive to do so. The situation in a BU world would be no different than now except that there would be no reliance on Core (or XT) to determine from on high what the options are. BU rejects the idea that it is the job of Core (or XT, or BU) developers to govern policy on consensus or restrict the conveniently available policy options on blocksize.

BU supporters believe that to have it otherwise is the tail wagging the dog: the finding of market-favored consensus is not aided, but rather hindered, by attempts to spoonfeed consensus parameters to the users. (This is putting it gently. Having a controversial parameter set at a specific number by default would be spoonfeeding, not even having the option to change it is more like force-feeding.)

Widespread adoption of BU, or adoption of BU-like configurability of settings within Core/XT, would relegate developer-led BIPs on controversial changes to the status of mere recommendations. Proposals like 2-4-8 would be taken into consideration, but would have to compete in the market on their own without the artificial advantage of the current barrier of inconvenience and technical ability (users having to mod their code to deviate from Core settings).

BU does not support bigger blocks, nor smaller blocks; it is rather a tool for consensus on blocksize to emerge in a more natural, market-driven way - free of market intervention as it were.

Adam, if you are confident that, for instance, 2-4-8 scaling is the best option and would be supported by the market, I think you should either support BU or support a Core BIP to make the blocksize settings configurable within the Core client.

Right now the leaders of the dominant Bitcoin implementation are for a low blocksize cap, but imagine if the situation reverses and big blockists are in control, to the consternation of many in the community. I think you would not want them locking down the settings. You might say, "You folks are doing fine otherwise, but you are off on the blocksize cap. Why try to play central planner? Please leave it up to the market if you are so sure the market will like your huge blocks. People will follow your recommendations if they like them anyway, so what are you worried about?"

If I were Core maintainer, I would do the same. Perhaps I would set a higher default, but I would not take the option away from the user. To do so risks sudden consensus shocks due to friction effects, risks my position being undermined silently, and most of all assumes I know better than everyone else. I might set it at 10MB. But I may be wrong; I'd rather trust in the market, because none of us knows better than a million people all with skin in the game.

As for how communication to settle on a Schelling consensus happens, besides the usual out-of-band communication that happens now in the debate, there is also interest in adding a tool within BU to efficiently communicate information about blocksize settings across the network, thereby facilitating an emergent consensus.

Quote from: adam3us on January 02, 2016, 05:58:17 PM

dynamic block-size game-theory

The game theory is the same as that arising in the choice of Core vs. XT vs. whatever (or among the BIPs by the miners and other stakeholders; if we look at the game theoretic considerations applying to the Core dev consensus process I'm sure you realize that problem is intractable). Miners and nodes have all the same choices now, except there is some additional friction introduced by Core's locking down of the blocksize settings, forcing miners and nodes to mod the Core code if they want to change them.

The question ought to be turned around: what are the game-theoretic considerations involved in having a monolithic reference client causing complicated issues of inertia, authority, and potential power grabs on top of the cleaner game theory? If tractability of a game theory analysis is the goal, surely BU is at least no more complicated than the situation under Core in the event of a hard fork.

Quote from: adam3us on January 02, 2016, 05:58:17 PM

How will the network not split into a myriad little shards without manual human coordination?

Ah. This is good. What I believe you are not noticing is that "manual human coordination" need not be top-down. Coordination can emerge, and it can be just as solid as any. Are you familiar with situations where it does? That would save a lot of ink.