Work on the "SegWit2x" compromise started in May. This may give Bitcoin a much needed capacity increase. Although this compromise seems very unpopular both among the "bigblock"-fraction and the "smallblock"-fraction, it may be the proposal that currently has the biggest probability to succeed.

In this article I intend to outline the different alternatives and give an overview of arguments for and against SegWit2x. I may not be entirely objective, though.

Recap of the Bitcoin capacity crisis

A 1 MB/10 minutes transaction data limit was hard coded in the Bitcoin protocol in the early days. Already in 2010 there were calls for lifting the limit, but it was procrastinated. In 2015 the debate started heating up, most was anticipating the limit to be increased, but there was no agreement on the details. The debate became more and more polarized during the next years, with "small blockers" rejecting increasing this limit at all, and the "big blockers" rejecting any alternative ways of increasing the capacity. I've touched the Bitcoin capacity limit and the ongoing debate on how to resolve this problem in several articles before, in particular:

• The bus analogy - why it can be expected that a transaction takes 12 hours to confirm every now and then
• The bitcoin forking risk - there can be only one bitcoin
• The big Reddit Bitcoin schism

Not everyone agrees there even exists such a thing as a "capacity crisis", but let me point out:

• Most of the use-cases people were dreaming about some few years ago aren't viable with the current situation. Except for being a pure speculative asset, there are very few use-cases left where Bitcoin is competitive with traditional banking solutions; from the top of my head, I can only think of bigger cross-country monetary transactions and criminal use-cases (including tax evasion). This isn't exactly the vision I signed up for when I became a Bitcoin-enthusiast and trader.
• The "bitcoin dominance"-meter at coinmarketcap has fallen from around 90% to around 40% during half a year. Although the accuracy of this meter may be discussed, it is rather dramatic.
• Many people, even including some former "bitcoin maximalists" are talking about "the flippening" - the event when some other crypto currency overtakes Bitcoin on being the crypto currency with biggest market cap. Most of the Bitcoin value hinges on the network effect, if some other crypto currency becomes bigger and more popular than Bitcoin, Bitcoin may soon become obsoleted.

Overview of major proposals

Currently there are three major initiatives for increasing the capacity (plus a lot of initiatives that haven't gained any traction) - the four alternatives now are:

• Increasing the block size limit using the "Emergent Consensus" flagging (the Bitcoin Unlimited algorithm).
• BIP-148 - the "User Activated Soft Fork"
• SegWit2x
• Status quo, still no capacity increase - not everyone agree Bitcoin is facing a capacity crisis.

The community split - how bad is it?

From my point of view, the very most of the actors in the bitcoin community wants both SegWit and bigger blocks - and then there are two rather noisy factions that strongly objects to either SegWit or bigger blocks. I believe the "hard core" of those two factions to be quite small, but it may be easy to get the impression that the community is thoroughly split into those two camps. I've earlier posted this comic strip (copyright smbc comics, original source at http://www.smbc-comics.com/?id=2939) - I believe it's very fitting for how the Bitcoin community have been developing during the last few years:

Many of you may be aware that there was a meeting already in February 2016 where miners and developers agreed on ... basically, SegWit2x. The miners signing this agreement has mostly been sticking to it. As it was obvious there wouldn't be any doubling of the base block size limit, most of the miners have either been rejecting SegWit or been opting for the emerging consensus alternative. On the developer side some of the core of the Bitcoin Core developers didn't sign the agreement and would veto any block size limit increase - and even the developers signing the agreement have apparently not have had any intentions to follow up on it. Particularly notable is Adam Back, who (through Blockstream) employs many of the said developers.

Arguments against 2MB-blocks

Centralization

One of the major arguments against bigger blocks have been that it will cause "centralization" - though the opponents of SegWit uses exactly the same argument against SegWit. The centralization risk is non-trivial to measure, even the definitions aren't that clear - Vitalik has written a post "The meaning of decentralization" (of course somehow biased).

Wrg of bigger blocks, the centralization risk may be real if the block size increases towards gigabytes - but for 2 MB, hardly so. There is one caveat though - we already have an unhealthy centralization with big mining pools being more profitable than independent miners or smaller mining pools, there are legitimate concerns that this may become very much worse if the block relay latency increases just a little bit. Then again, the latency-issue has been more or less mitigated over the last few years (head-first mining, Matts relay network, xtreme-thin-blocks, FIBRE, etc), so 2 MB blocks should not pose any significant advantages neither to the bigger pools nor to Chinese miners in general.

Protocol change

Some very few hard-liners claim that the 1 MB-limit is an essential part of the Bitcoin protocol, and altering it would be sort of a "breach of contract". I think this argument may be dismissed as the same applies to any of the numerous soft-forks that have been pushed through.

Slippery slope

The "slippery slope"-argument may have some merit. If we allow 2 MB now, the road may be paved for 2 GB-blocks in the near future. While some of the biggest mining pools will probably be happy to produce 2 GB blocks, it would be very bad for the rest of the network.

Hard fork / chain split

Increase of the block size limit can only be done through a hard fork, hard forks requires all nodes in the network to upgrade - such upgrades may be difficult to force through. Miners/nodes that haven't upgraded the software will end up on a different chain than the rest of the world - the risk of a chain split may be a real concern. Then again, if the vast majority of miners upgrade, anyone on the wrong chain will simply observe that transactions aren't getting confirmed - the real risk is only if parts of the network denies upgrading. If the only real reason for denying an upgrade is that one is afraid of a chain split ... well, that's a rather circular argument, isn't it? I find it particularly amusing that some people argue a lot that a hard fork should be avoided by all means, and in the next breath they promote BIP-149 (aka UASF) which is also likely to cause a chain split.

One of the arguments is that we do not need to increase the block size through a hard fork - it is sufficient to embed hashes in the blockspace, referencing to out-of-block-data, i.e. sidechains, drivechains, extention blocks or whatever. Personally I think increasing the block size limit is a much cleaner and simpler approach - and I'm both a developer and a sysadmin, I'm very well aware of the "upgrade pain".

Kicking the can / too little too late

Two megabytes are simply not enough, it's too little too late. It will cause a temporary relief but it will very soon be needed to increase the limit further. It's like kicking the can.

Other

Lots and lots of arguments have been put forth against increasing the block size - but I believe there doesn't exist any other legitimate arguments. Please prove me wrong in the comments.

Arguments against SegWit

Probably almost everybody agrees it is important to segregate the signature from the transaction. There aren't many valid technical arguments against SegWit, but they do exist.

SegWit is considered "ugly"; the backward-compatibility-constraint causes a lot of extra complexity, quite much of the code base has been rewritten to support SegWit, from an engineering-point-of-view this is rather bad. There does exist an alternative proposal, Flexible Transactions aka FlexTrans. From my point of view, FlexTrans seems to be a much cleaner approach than SegWit, though FlexTrans is a hard fork, it does require everyone to upgrade.

For a non-upgraded node the SegWit transaction output appears like money anyone can spend. Craigh Wright has pointed out that this may skew miners incentives to safeguard the rules - though the argument doesn't seem much valid in my point of view - if evil miners with a majority of the hash power can revert rules like SegWit, they can also change the rules to increase the mining reward. Please prove me wrong in the comments.

On the political side, there are other reasons to reject SegWit, with various legitimacy;

• The most significant reason is that if we'll be accepting SegWit without demanding a block size increase, we may never get a block size increase.
• It has been said that the current SegWit implementation is an artificial construction, the main purpose is to segregate the signatures, the promised capacity increase is just a "sugar pill".
• Some people also argue that it's bad to throw in a hard-coded 4x discount given on the usage of transaction inputs, for many liberalists and anti-communists "economical constants decided by a central comitee" are considered to be evil.
• The SegWit-supporters argues that the discount is a very good thing as it will encourage the actors to spend their UTXOs, reducing the UTXO bloat. The opposite could also become reality, creation of more SegWit-UTXOs because those are known to be cheap to spend. The typical end-user-wallet wouldn't care, it would anyway typically use one UTXO input and produce two new UTXOs whenever possible.

Other arguments against SegWit2x

With SegWit2x, the theoretically maximum actual block size limit is 8 MB, which may be considered excessive. The original intention with the 1MB limit may have been (no original source exists as far as I know) to prevent a DoS-attack, such an attack would apparently be 8 times as bad with SegWit2x. Then again, the actual attack vector of concern is a computationally hard transaction with extreme amount of inputs taking a lot of computational power to verify. The 8 MB block would need to contain only SegWit transactions, which can be verified in linear time.

Covert reasons

Often the arguments put forth are just "straw arguments", while there are other real reasons why the different actors are pulling in different directions. I will not dwell too much in this, actually I'm not at all sure what is to be considered as tin-foil-hat conspiracy theories vs what is to be believed in. I tend to say that sometimes the difference between naivety and paranoia may be razor thin. Anyway, here is some of the rumors that are out there:

• Antpool is very much against SegWit, as they benefit from special technology (covert asicboost) that would be obsoleted by SegWit (if this is true, it could be the number one most legitimate reason for activating SegWit ASAP).
• Miners in general needs bigger blocks to keep up their transaction fee revenue stream. If transactions will be flowing through offchain solutions, the transaction fees will go to other actors. Hence miners are fighting against off-chain transaction technologies.
• Bitcoin is disruptive technology, it will cause very much harm to actors having invested a lot into the finance/banking sector, governments dependent on collecting tax revenues, CIA, etc. The typical claim goes that the other side is controlled by dark forces, intending to derail the whole Bitcoin project. I have my own pet conspiracy theory: Both fractions are controlled by dark forces intending to derail the project and deprive Bitcoin from any meaningful capacity increase. They have succeeded pretty much in the latter so far.
• The Blockstream company is specializing on sidechains and lightning, technologies dependent on SegWit. Further, to maximize profits from sidechains and lightning, it's important with capacity problems on on-chain transactions, or people won't be willing to pay for those technologies.
• The Blockstream company has various patents on SegWit, sidechains and lightning (if Blockstream has patents on SegWit, that could indeed be the number one most legitimate reason to avoid SegWit)

Conclusion

We need both SegWit and bigger blocks, and there are few real legitimate arguments against either SegWit or bigger blocks.

I hope and believe the SegWit2x proposal will go forward, as it may rescue Bitcoin from it's current crisis.