Aber die Christen haben sich ja auch nicht verdoppelt als Luther neue Rules
vorgeschlagen hat und die dann geforked haben.

Das ist eben der Unterschied zwischen physischer Realität (Menschen, Gold) und Fiat (USD, Bitcoin)

--
"Der Computer ist die logische Weiterentwicklung des Menschen: Intelligenz ohne Moral." (John Osborne)
"Der Gutmensch ist die logische Rückentwicklung des Menschen: Moral ohne Intelligenz." (unbekannt)

... und schon gar keine limitierte Blockchain. Jorge Stolfi, Professor of Computer Science, erklärt es hier:

If SegWit is an engineering aberration, SegWit2X is much worse. Since it includes an increase in the limit from 1 MB to 2 MB, it will be a hard fork. But if it is going to be a hard fork, there is no justification to use SegWit to fix the MLB: that bug could be fixed by the much simpler method mentioned above.

Im Detail:

In my understanding, allowing Luke to run his node is not the reason, but only an excuse that Blockstream has been using to deny any actual block size limit increase.

The actual reason, I guess, is that Greg wants to see his "fee market" working. It all started on Feb/2013. Greg posted to bitcointalk his conclusion that Satoshi's design with unlimited blocks was fatally flawed, because, when the block reward dwindled, miners would undercut each other's transaction fees until they all went bakrupt. But he had a solution: a "layer 2" network that would carry the actual bitcoin payments, with Satoshi's network being only used for large sporadic settlements between elements of that "layer 2".

(At the time, Greg assumed that the layer 2 would consist of another invention of his, "pegged sidechains" -- altcoins that would be backed by bitcoin, with some cryptomagic mechanism to lock the bitcoins in the main blockchain while they were in use by the sidechain. A couple of years later, people concluded that sidechains would not work as a layer 2. Fortunately for him, Poon and Dryja came up with the Lightning Network idea, that could serve as layer 2 instead.)

The layer 1 settlement transactions, being relatively rare and high-valued, supposedly could pay the high fees needed to sustain the miners. Those fees would be imposed by keeping the block sizes limited, so that the layer-1 users woudl have to compete for space by raising their fees. Greg assumed that a "fee market" would develop where users could choose to pay higher fees in exchange of faster confirmation.

Gavin and Mike, who were at the time in control of the Core implementation, dismissed Greg's claims and plans. In fact there were many things wrong with them, technical and economical. Unfortunately, in 2014 Blockstream was created, with 30 M (later 70 M) of venture capital -- which gave Greg the means to hire the key Core developers, push Gavin and Mike out of the way, and make his 2-layer design the official roadmap for the Core project.

Greg never provided any concrete justification, by analysis or simulation, for his claims of eventual hashpower collapse in Satoshi's design or the feasibility of his 2-layer design.

On the other hand, Mike showed, with both means, that Greg's "fee market" would not work. And, indeed, instead of the stable backlog with well-defined fee x delay schedule, that Greg assumed, there is a sequence of huge backlogs separated by periods with no backlog.

During the backlogs, the fees and delays are completely unpredictable, and a large fraction of the transactions are inevitably delayed by days or weeks. During the intemezzos, there is no "fee market' because any transaction that pays the minimum fee (a few cents) gets confirmed in the next block.

That is what Mike predicted, by theory and simulations -- and has been going on since Jan/2016, when the incoming non-spam traffic first hit the 1 MB limit. However, Greg stubbornly insists that it is just a temporary situation, and, as soon as good fee estimators are developed and widely used, the "fee market" will stabilize. He simply ignores all arguments of why fee estimation is a provably unsolvable problem and a stable backlog just cannot exist. He desperately needs his stable "fee market" to appear -- because, if it doesn't, then his entire two-layer redesign collapses.

That, as best as I can understand, is the real reason why Greg -- and hence Blockstream and Core -- cannot absolutely allow the block size limit to be raised. And also why he cannot just raise the minimum fee, which would be a very simple way to reduce frivolous use without the delays and unpredictability of the "fee market".

Before the incoming traffic hit the 1 MB limit, it was growing 50-100% per year. Greg already had to accept, grudgingly, the 70% increase that would be a side effect of SegWit. Raising the limit, even to a miser 2 MB, would have delayed his "stable fee market" by another year or two. And, of course, if he allowed a 2 MB increase, others would soon follow.

Hence his insistence that bigger blocks would force the closure of non-mining relays like Luke's, which (he incorrectly claims) are responsible for the security of the network, And he had to convince everybody that hard forks -- needed to increase the limit -- are more dangerous than plutonium contaminated with ebola.

SegWit is another messy imbroglio that resulted from that pile of lies. The "malleability bug" is a flaw of the protocol that lets a third party make cosmetic changes to a transaction ("malleate" it), as it is on its way to the miners, without changing its actual effect.

The malleability bug (MLB) does not bother anyone at present, actually. Its only serious consequence is that it may break chains of unconfirmed transactions, Say, Alice issues T1 to pay Bob and then immediately issues T2 that spends the return change of T1 to pay Carol. If a hacker (or Bob, or Alice) then malleates T1 to T1m, and gets T1m confirmed instead of T1, then T2 will fail.

However, Alice should not be doing those chained unconfirmed transactions anyway, because T1 could fail to be confirmed for several other reasons -- especially if there is a backlog.

On the other hand, the LN depends on chains of the so-called bidirectional payment channels, and these essentially depend on chained unconfirmed transactions. Thus, given the (false but politically necessary) claim that the LN is ready to be deployed, fixing the MB became a urgent goal for Blockstream.

There is a simple and straightforward fix for the MLB, that would require only a few changes to Core and other blockchain software. That fix would require a simple hard fork, that (like raising the limit) would be a non-event if programmed well in advance of its activation.

But Greg could not allow hard forks, for the above reason. If he allowed a hard fork to fix the MLB, he would lose his best excuse for not raising the limit. Fortunately for him, Pieter Wuille and Luke found a convoluted hack -- SegWit -- that would fix the MLB without any hated hard fork.

Hence Blockstream's desperation to get SegWit deployed and activated. If SegWit passes, the big-blockers will lose a strong argument to do hard forks. If it fails to pass, it would be impossible to stop a hard fork with a real limit increase.

On the other hand, SegWit needed to offer a discount in the fee charged for the signatures ("witnesses"). The purpose of that discount seems to be to convince clients to adopt SegWit (since, being a soft fork, clients are not strictly required to use it). Or maybe the discount was motivated by another of Greg's inventions, Confidential Transactions (CT) -- a mixing service that is supposed to be safer and more opaque than the usual mixers. It seems that CT uses larger signatures, so it would especially benefit from the SegWit discount.

Anyway, because of that discount and of the heuristic that the Core miner uses to fill blocks, it was also necessary to increase the effective block size, by counting signatures as 1/4 of their actual size when checking the 1 MB limit. Given today's typical usage, that change means that about 1.7 MB of transactions will fit in a "1 MB" block. If it wasn't for the above political/technical reasons, I bet that Greg woudl have firmly opposed that 70% increase as well.

If SegWit is an engineering aberration, SegWit2X is much worse. Since it includes an increase in the limit from 1 MB to 2 MB, it will be a hard fork. But if it is going to be a hard fork, there is no justification to use SegWit to fix the MLB: that bug could be fixed by the much simpler method mentioned above.

And, anyway, there is no urgency to fix the MLB -- since the LN has not reached the vaporware stage yet, and has yet to be shown to work at all.