Bitcoin users and – in particular – miners are, therefore, faced with a choice. Will they support Bitcoin XT and vote for an 8 megabyte block-size limit – doubling every other year? Or will they stick to Bitcoin Core with 1 megabyte blocks, limiting the Bitcoin network to a maximum of seven transactions per second?

Or at least that is the choice as it is often presented. In reality, the possibilities are not binary. At the time of publication of this article, two other Core developers have proposed three more Bitcoin Improvement Proposals (BIPs) to increase the block-size limit, and an even wider spectrum of ideas has been suggested on the development mailing list, forums, chat rooms and other media. This article presents an – undoubtedly incomplete – overview of these ideas, categorized in six types of solutions.

Solution 1: No Cap on Block Size

A first option is a full removal of the block-size limit. Such a cap on the block size, after all, constricts the number of transactions on the Bitcoin network, which could become a barrier to adoption or utility at scale.

Satoshi Nakamoto originally implemented the block-size limit as a quick fix to avoid denial-of-service (D0S) attacks on the Bitcoin network. But since Bitcoin's creator has gone silent, most of Bitcoin's developers have come to believe that the block-size limit might actually serve more purposes than just the prevention of DoS attacks. The arguments to keep a block-size limit today are diverse, but can be divided into two main categories.

First, a block-size limit might be needed to avoid centralization of the Bitcoin network, and, in particular, further centralization of mining. Perhaps most importantly, bigger blocks would take longer to propagate to other miners when first found. A longer propagation time should lead to a higher orphan rate, as more miners would be mining on older blocks, while newer blocks are still finding their way through the network. That would, in turn, incentivize miners to join larger miner pools, as they find blocks more often, and therefore don't need to wait for the propagation of new blocks as often.