https://en.wikipedia.org/wiki/Robustness_principle

“Be conservative in what you send, be liberal in what you accept”

That is the correct criterion / terminology / conceptual framework which should have been used this whole time, when attempting to determine whether an “upgrade” to Bitcoin would still be “Bitcoin.”

The incorrect criterion / terminology / conceptual framework to use is the meaningless unprofessional gibberish from Core/Blockstream about “hard-forks” versus “soft-forks” versus “soft hard-forks” or “firm-forks” etc.

The informal statement of the Robustness Principle above has an even more precise phrasing using concepts and language from Type Theory (another example of a vitally important area of Computer Science which most Core/Blockstream “devs” are woefully ignorant of, since they’re mainly just a bunch of insular myopic C/C++/Java/JavaScript procedural-language pinheads or “C-tards”).

The Robustness Principle, restated more formally using concepts and language from Type Theory, simply states that:

The → type constructor is contravariant in the input type and covariant in the output type

https://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29#Function_types

Unfortunately, most Core/Blockstream “devs” do not seem to understand:

• that → is a “type constructor” (they probably only understand it as “that funky mathematical symbol which shows what a function returns”), or

• what terminology like contravariant in the input type and covariant in the output type even means in the first place

… unless they happen to have studied a well-designed high-level, functional language like C# at some point in their limited so-called “careers” as devs.

Unfortunately, their brains have been tragically trapped and stunted by focusing on low-level, procedural languages like C/C++ – simply due to their unfortunate prioritizing of being able to program “close to the machine,” which is of course essential in terms of raw efficiency of implementations, but which is horribly limiting in terms of conceptual expressiveness of specifications (and satisfaction of real-world user requirements).

Basically what this all means is that pithy insults such as calling them “pinheads” or “C-tards” actually do provide a useful shorthand capturing a very real aspect of the weakness of their development process: It bluntly and compactly expresses the blatant and tragic fact that they are mere system coders / implementers trapped in the conceptual dungeon of lower-level procedural languages like C/C++ which are “closer to the machine” – rather than actual system designers / specifiers who could have had the conceptual freedom of at least being able to think and communicate using notions from higher-level functional languages like Haskell, Ocaml or C# which are “closer to the problem domain” (and hence also “closer to the users” themselves and their actual needs – a constituency whose needs these C/C++ devs have consistently and tragically ignored while they fail to deliver what users have been demanding for months: e.g. simple safe scaling via moderate blocksize increases).

Probably the only prominent Core/Blockstream dev who does understand this kind of stuff like the Robustness Principle or its equivalent reformulation in terms of covariant and contravariant types is someone like Pieter Wuille – since he’s a guy who’s done a lot of work in functional languages like Haskell – instead of being a myopic C-tard like most of the rest of the Core/Blockstream devs. He’s a smart guy, and his work on SegWit is really important stuff (but too bad that, yet again, it’s being misdelivered as a “soft-fork,” again due to the cluelessness of someone like Luke-Jr, whose grasp of syntax and semantics – not to mention society – is so glaringly lacking that he should have been recognized for the toxic influence that he is and shunned long ago).

The terminology above based on the Robustness Principle (and not their meaningless gibberish about “hard-forks” versus “soft-forks” versus “soft-hard forks” or “firm-forks etc.) is what provides the correct criterion and mental framework for deciding what kind of “upgrades” should be allowed in Bitcoin.

In other words:

Upgrades which make the client protocol as conservative (or more conservative) in terms of what the client can send, and as liberal (or more liberal) in terms of what the client protocol can receive SHOULD STILL BE CONSIDERED “BITCOIN”.

If any of those low-level C/C++ Core/Blockstream “devs” had gotten enough Computer Science education somewhere along the way to learn the correct, more formal mathematical / computer science terminology and mental framework provided by the Robustness Principle (or by the equivalent concept from Type Theory stating that that “the → type constructor is contravariant in the input type and covariant in the output type”), then it would have been crystal-clear to them that an upgraded client which can accept bigger blocks (but which does not require sending bigger blocks (e.g., clients such as Bitcoin Unlimited and Bitcoin Classic – or even Core with bigger blocks) would still “be Bitcoin”.

---

Aside:

And let’s not even get started on that idiot Theymos who is utterly beneath contempt here. It is pathetic and sad that someone so ignorant about coding and communities has been considered in some sense “part of Core” as well as being allowed to be in charge of delimiting the boundaries of what is and what is not “permissible” subject-matter for debate and discussion on something as groundbreaking and innovative as Bitcoin.

He’s clearly been in way above his head this whole time, and his inability to grasp what is and isn’t an “upgrade” to Bitcoin is one of main reasons we are where we are today, with the community divided and acrimonious, with debates dominated by toxic trolls deploying rhetorical techniques reminiscent of fascist political regimes, unaware that they are merely the kind of textbook caricatures that automatically infest any place wherever the Milgram experiment gets carried out.

His pathway to learning Computer Science was like most deprived benighted geeky kids from the backwoods of the US in his generation: he has publicly and proudly (and poignantly) stated that he was, to his mind, “lucky enough” to be able to pick up JavaScript and PHP (simply because those are the languages that power the browser, so they must be good) – blissfully unaware of the fact that PHP is generally regarded by serious coders as being a “fractal of bad design”, and JavaScript is more properly understood to be the “low-level assembly language of the web browser,” as evidenced by the proliferation we are finally seeing of languages which compile to JavaScript, due to the urgent need (already mentioned above) to liberate programmers from the conceptual dungeon of being forced into thinking “at the level of the machine” and allow them to instead work “at the level of the problem domain” – ie, at the level of actual user requirements.

That is the only level where programmers can actually solve real problems for real users, instead of being generally useless and counterproductive and downright destructive, as most Core/Blockstream devs have turned out to be.

Note that the main successes which Core/Blockstream devs like to point to tend to involve re-implementing an existing specification (i.e., merely tweaking and providing efficiency improvements). For example, recall the case they so often proudly point to: their reimplementation of libsecp256k, where the “hard” conceptual thinking (which is basically beyond most of them) had already done for them by earlier programmers, and all they contributed was a more efficient implementation of an existing specification (and not a new specification unto itself).

This is because – as we have seen with their pathetic bungling of the simplest capacity upgrade specified by the creator of Bitcoin – these Core/Blockstream “devs” could not program their way out of a wet paper bag, when it comes to actually implementing necessary features that satisfy actual user needs & requirements.

---

So, as we have seen, Bitcoin’s so-called “development” is being “led” by a bunch of clueless noobs who think that “being a dev” is about learning whatever implementation languages they happen to find laying around in their little limited world – mostly low-level procedural languages.

This is why they’re only good at understanding “how” to do something. Meanwhile they are utterly incapable of understanding “what” actually needs to be done.

And “what” needed to be done here was abundantly clear in this case – the community has been telling them for months (and alt-coins, by the way, have been implementing these kinds of things). All they had to do was listen to what the community needed, and understand that a Bitcoin that can handle bigger blocks is still Bitcoin, and code that – and then Bitcoin would still safely be far-and-away the top cryptocurrency for now and the foreseeable future (a status which it now no longer so undisputedly enjoys).

They do not have even the most rudimentary understanding of Theoretical Computer Science, because if they did, they would have picked up at least some of these basic Wikepedia-level notions of Type Theory at some point along the way – and they would have understood that the whole “upgrading Bitcoin” debate should properly be framed in terms of the Robustness Principle of “Be conservative in what you send, be liberal in what you accept” aka the notion that “the → type constructor is contravariant in the input type and covariant in the output type” – and then it would have been instantly and abundantly clear to them that a client protocol upgrade which allows increasing the blocksize (despite the totally irrelevant fact that it does happen to involve actually installing some new code on the machine) is still “Bitcoin” by any reasonable definition of the term “Bitcoin.”

It was their horrifying failure to understand this elementary Computer Science stuff which allowed idiots like Theymos to mislabel a simple capacity upgrade as an “alt-coin” simply because of the irrelevant historical accident that making a computer system more generalized happens to require installing new code, while making a computer system more specialized does not (which, if you’ve been following along with the concepts here, is actually just yet another reformulation of the Robustness Principle).

When phrased in the proper terminology like this, it becomes clear that the true criterion about whether or not an upgrade is still in some sense “essentially the same” as the previous version has nothing to do with whether new binaries need to be copied onto everyone’s machine or not.

The only thing that matters is the (new versus old) behavior of the code itself – and not whether (or not) different code needs to be installed in order to provide that behavior.

I have no idea whether I’ve been making myself sufficiently clear on this or not. I do hope that people will understand the crucial distinction I’m trying to make here between the desired behavior of the network (which is obviously the only relevant issue), versus whether achieving that behavior does (or does not) require distributing and installing new code on every node of that network.

The only relevant question is the behavior of the network – and not the installation steps that may (or may not) be required to get there.

Or to put it in terms more commonly used in the computer programming industry, which perhaps might be more broadly accessible: The Core/Blockstream devs are tragically confusing rollout issues with behavior issues. The two are orthogonal and should not be mixed up!

The only relevant criterion – which I’ll state again here in the hopes it might eventually sink in through the thick skulls of some clueless Core/Blockstream dev – is:

Upgrades which make the client protocol as conservative (or more conservative) in terms of what the client can send, and as liberal (or more liberal) in terms of what the client protocol can receive ARE STILL “BITCOIN” (i.e., they are not alt-coins).

Obviously, a blocksize increase in Core itself (and by the way, this would have been the simplest and “least contentious” approach, if our so-called leaders had understood the elementary Computer Science outlined in this OP), or a blocksize increase provided by Bitcoin Classic and Bitcoin Unlimited, would clearly satisfy that criterion, so they are still Bitcoin (and they are most emphatically not alt-coins).

---

At this point, it might be nice if we had a new term like “Streisanded” to capture the clusterfuck we now find ourselves in due to the incompetence of Core/Blockstream / Theymos / Luke-Jr / Adam Back / Greg Maxwell – where an actual alt-coin like Ether now is starting to gain traction (and they’ve ironically ended up having to allow discussion of it on their inconsistently censored forum r\bitcoin despite because of all their misguided and erroneous attempts to label Bitcoin Classic and Bitcoin Unlimited or Core-with-2MB-blocks as alt-coins) – and meanwhile here we are with an artificially suppressed price and artificially congested network, because our so-called “leaders” got the distinction between an alt and an upgrade totally backwards.

Of course, some of us might also believe that the investors behind Blockstream (most of whom, to put it in the simplest terms, probably feel, each in their own way, that they are “short Bitcoin” and “long fiat” and therefore do not want Bitcoin to succeed) are perhaps quite happy to have devs (and a community) who have been ignorant of basic Computer Science stuff like the Robustness Principle – so they’ve let this debate fester on using the wrong terminology for years – and so here we are today:

• Instead having a innovative community and a coin whose value is steadily rising and a network smoothly processing our transactions… all that cool stuff is happening with an actual alt-coin.

• And meanwhile, the simple upgrade we should have had is still tragically and erroneously mislabeled as an “alt-coin” by a large chunk of the community, and we have stagnant debate, misinformed debaters, an undelivered roadmap, an artificially congested network, artificially depressed volume, an artificially suppressed price, and potential new adopters (and coders) staying away in droves.

And this tragedy has happened because:

• we let our development be led by people who know a few things about coding but actually surprisingly little about Computer Science in general, and

• we let our discussions be led by people who know a few things about how to control communities but very little about how to help them grow.