Great to see you here, Meni. I have long admired your prescience as one of the first to recognize the benefits of fork arbitrage. There's one major misconception in your post I want to delve into: [Bitcoin Unlimited] gives way too much power to miners Since BU lets everyone easily set their blocksize settings to match Core's, I hope you will grant that strictly speaking any power given to miners is not coming from BU itself but from users deliberately choosing more permissive blocksize settings. (Unless you mean the default settings not matching Core, which I think is a fairly trivial objection, and would anyway be quickly remedied if the defaults were a common concern.) Leaving aside the question of bugs, then, people merely running BU is clearly not a problem, miner-power-wise. Therefore I assume your concern is that users would voluntarily choose to set their blocksize caps in some other way that is problematic. Perhaps too large, uncoordinated, shifting, etc. Yet the only way it was ever possible to deter people from doing that is to disallow blocksize setting adjustment, as Core does. Obviously this barrier of inconvenience couldn't ever be sustainably effective as a deterrent, and is now not effective at all as people can easily download BU or Classic. Unless you condone censorship of these repos as a solution, which it seems you don't (and it would be unsustainable anyway). Perhaps here you will say, "BU exists, yes it was bound to happen, but we can still rightly warn people against running it." But as I said at the start, people merely running BU cannot give miners any extra power, as they can run it with Core settings (or even stricter ones). Thus, again forgetting about bugs for now, the correct admonition would not be against running BU, but against using BU to deviate from current Core settings. Now considering that Classic and other clients also feature adjustable blocksize, can't we safely convert your original statement to the following more precise one? "People adjusting their blocksize settings in certain ways in otherwise-Core-compliant implementations would give miners way too much power." If this is true, then we should warn them against doing so, and advise them to run certain settings "we" experts or devs or pundits or redditors or investors(?) recommend, whether that means strictly Core settings or something else. That is all we can do now, right? Here finally you may say, "Wait, so BU itself doesn't actually do anything really, so what's the point?" The point is rather subtle: under the old paradigm, Core dev handed down consensus settings from on high, expecting that this was sufficient to keep every client in consensus. Before any settings became controversial it was indeed sufficient, but that merely hid the fact that when controversy around consensus settings were to arise, this inconvenience factor in changing your consensus settings away from Core's (i.e., having to mod your Core code and recompile, or having to find a trustworthy dev to mod it for you) would no longer be a sufficient deterrent, especially as dev teams would sprout up to provide these mods at the touch of a button. Under this new paradigm, the developers (Core, BU, Classic, etc.) are cut out of the loop, or at least not given any special influence in deciding what consensus settings users choose or converge on - other than the weight of their recommendations. The old paradigm, pre-controversy, hid the fact that reaching consensus on a controversial protocol setting - perhaps even by definition - requires users to have a fully unhindered choice (no inconvenience barriers) so that they may be said to properly have come to an agreement. The pre-controversy situation obscured the fact that users reaching agreement on a protocol setting involves converging on Schelling points. The pre-controversy situation also concealed the fact that while in the absence of controversy there is no undue developer influence on users' choice of Schelling points despite settings being "bolted down" in the code (e.g., no one really disagrees with Core about the 21M coin limit), under controversy this bolted-down model gives the Core dev team undue ability to sway consensus-finding on those controversial protocol settings. Thus Bitcoin Unlimited, in stripping away the inconvenience barrier to users adjusting a "forbidden" setting, serves largely as an argument in code form. It merely makes it more clear that devs shouldn't, and indeed don't (in any sustainable way), have any special influence in the process of Bitcoin users coming to consensus. It lets users coordinate to agree on consensus settings without having to change dev teams whenever they wish to transition to a new Schelling point for the blocksize cap or any other controversial setting (in keeping with this, BU should in principle also include optional Segwit signalling, as it is also controversial). In other words, the idea of BU and Classic is to unbundle the consensus settings from the dev teams. It is a recognition that users should ideally be able to shop for dev teams without having to align with those teams' stances on controversial matters. I hope it is clear that BU, Classic, BitcoinEC, and other adjustable blocksize cap clients do not give any extra power to miners. They merely start to remove the extra influence the Core dev team has, or accelerate the realization that such influence is fleeting and cannot be relied upon to secure Bitcoin. Only the will of the stakeholders can over the long term influence consensus-finding. By the way, any bugs in non-Core implementations and any amateurishness in non-Core devs should only make the above points about Core having undue influence in consensus-setting more alarming. BU might not be the best choice code-quality-wise, but insofar as that is the case, getting devs out of the consensus-jiggering business is to that degree an even more pressing matter.