Yep, you got. EDIT: At least that's how I see it. There are many ideas about how it might go. I prefer to focus on the user-selectable blocksize limit only, because that is a simpler issue. Besides, the other features can be turned off easily until they have more theoretical and experimental vetting. Or a forked client can be offered without those other options if people think that's too dangerous an option to give to the user. So I don't see it as material to the main question of whether it's a good idea to allow users to set the blocksize themselves.


I mentioned this above, but things like BIP101, BIP102, etc. will be selectable as options. Consider a scenario where XT/BIP101 were adopted. The difference between the current situation and a scenario where BU is dominant:

• Current situation: People notice the majority is moving to XT, flagging support for BIP101, so even the Core users switch to XT. On the flag day some stragglers might remain and cause a fork.
• If BU is the dominant implementation: People notice the majority is moving to BIP101, flagging support for BIP101, so even people that prefer 1MB or 2MB or whatever switch to BIP101. On the flag day some stragglers might remain and cause a fork.

Doesn't seem that different, right? The only real difference is that options aren't just Core's chosen blocksize cap and BIP101. There would be BIP102, etc. to choose from, as well as other options not given by Core or XT. It'd be very much like there weren't just Core and XT, but Core, XT, and a bunch more to choose from, and we see who wins - just like now except with BU the consensus-parameter-setting is unbundled from the secure-code-providing service of the Core/XT/etc. devs.

Rather than being spoonfed consensus options from an ivory tower (or two ivory towers), there are many options. Convergence on one options happens the same way, for the same reasons - just smoother.