Bitcoin Scaling Problem

An article that I believe is relevant with the Segwit 2x fork coming out in this month.

https://cointelegraph.com/explained/bitcoin-scaling-problem-explained

Does Bitcoin have a scaling problem?
Yes, it does. It has been unresolved for a while and is getting worse with time.

Bitcoin runs on the software created by a programmer or a group of programmers known as Satoshi >Nakamoto back in 2007-09. Despite the many improvements, which have been made by contributing >developers over the course of Bitcoin’s existence, the code base is still pretty similar to what it was eight >years ago and some of the limitations are still there.

The problem is, the current landscape of the Bitcoin ecosystem is very different from what it used to be >back at the inception of the cryptocurrency. The number of people involved has grown from a few dozens >of passionate enthusiasts to over 10 mln of everyday users.

The growing user base is naturally accompanied by a constantly increasing number of daily transactions, >which are now counted by the hundreds of thousands. The unfortunate reality is that the Bitcoin network, i>n its current state, is unable to process all those transactions fast enough.

Why is Bitcoin unable to cope with all the transactions?
The problem lies in a specific parameter called the “block size limit.” The current limit is insufficient for the >ever-growing transaction intensity.

First, a very quick and basic introduction to how Bitcoin works for those who don’t know. All the >transactions that have ever taken place in the Bitcoin network or will ever take place, are recorded on a >public and immutable ledger called “The Blockchain.”

As follows from its name, the Blockchain is a sequence of blocks. Each block, in turn, is a >cryptographically sealed collection of all transactions which have happened in the network over the past >ten minutes. Every new block is permanently added to the end of the Blockchain so that every user can >always check that each specific transaction has indeed taken place.

Back in 2010, Nakamoto introduced a block size limit of 1mb, meaning that blocks over the size of 1 >megabyte would be automatically rejected by the network as invalid. This was a security measure, >designed to prevent potential DoS attacks by hackers creating blocks of huge, or even infinite size and >broadcasting them across the network in order to paralyze it.

That decision, however, has had an adverse long-term effect on the transaction capacity of the network.

Each transaction consists of important data: the sender, the recipient, the amount of Bitcoins in transfer, >etc. That data takes some space, which is quite insignificant when talking about a single transaction. But it >adds up when there are hundreds of transactions taking place every minute.

The current size limit of one megabyte per block can realistically support three to seven Bitcoin >transactions per second. The problem here is that for the network of the current proportions that is already >not enough. And it’s only getting worse as the user base keeps growing.

What are the results of the insufficient block size limit?
The increase in average transaction times and fees. Basically, Bitcoin is gradually turning into a functional >analog of wire transfers.

On a regular day, the Bitcoin network is still able to operate normally. However, sometimes it manages to >reach peak loads and that’s when things get rough. Many users have been reporting wait times of several >hours or even days on their transactions.

Moreover, the speed at which Bitcoin miners are likely to process any particular transaction depends >directly on the size of the miners’ fee, set by the sender for every transaction. This creates a market of >transaction fees: in order to have their transfers processed faster, the users have to compete with each >other by setting ever increasing fees.

In the early days, the commissions were measured in mere fractions of a cent. Today, however, if you want >to send the coins fast, you will have to pay a fee worth several cents or even dollars.

Both the transaction times and the fee sizes have been gradually increasing for the past several months, >making Bitcoin look more like a functional counterpart to bank transfers. That is an existential threat to the >cryptocurrency: if we have a more popular and widespread alternative to Bitcoin, why even use it at all?

Is there a solution to the scaling problem?
There have been many proposed ways to solve it, none of which have been realized as of today.

The scaling problem has been under scrutiny for quite a while. Arguably, the first two serious attempts at >fixing it were BIP 100 and BIP 101, where BIP stands for Bitcoin Improvement Proposal. They were >introduced in 2015 by the Bitcoin core developers Jeff Garzik and Gavin Andresen respectively.

Both were aimed at increasing the block size limit and both were hard-fork solutions, meaning that if they >got implemented, older versions of Bitcoin software would become incompatible with the new network. The >difference between them was that BIP 100 was about making the block size limit adjustable by the >decision of miners, whereas BIP 101 was a straightforward one-time increase from 1mb to 8mb.

In regards to which proposal should be implemented, there were heated debates throughout the Bitcoin >community for the most part of 2015. Still, it proved fruitless. Neither BIP 100 nor BIP 101 have been >realized in any noticeable way in the network today.

History seems to repeat itself and today there are again two different solutions competing for approval by >the community: Bitcoin Unlimited and SegWit. The problem of Bitcoin’s insufficient capacity is now much >more critical than it used to be back in 2015, and still, there is no clear leader in the heated, highly >politicized competition between the two proposals.

How do BU and SegWit propose to scale Bitcoin up?
Bitcoin Unlimited aims to remove the block size limit altogether, thereby allowing the miners to reach a >consensus on their own. SegWit offers a moderate increase of the block size to up to 4 megabytes moving >some non-critical data out of the blocks.

Bitcoin Unlimited is a direct evolution of the previous unsuccessful attempts to resolve the block size >debate. Seeing how the ideas of increasing the limit, or making it incrementally adjustable, have failed to >garner enough support, BU is aimed at abolishing the limit altogether. Instead, it makes it so that miners >can create blocks of arbitrary sizes and broadcast them across the network, competing with each other for >a place on the Blockchain.

SegWit offers another solution. It was originally created to fix an unrelated issue - transaction malleability. >To put it shortly, getting rid of transaction malleability required moving some non-critical data, called >“witness data”, out of transactions and off the Blockchain.

This allows for an increase in the block sizes of up to 4MB, although most experts close to the >development process say that the network is most likely to settle at about 2MB block sizes after SegWit is >launched.

There is also another way SegWit could increase transaction capacity, albeit not directly. Fixing the >transaction malleability makes the Bitcoin network secure enough to build off-the-Blockchain solutions on >top of it, such as the Lightning Network, for instance. That could make Bitcoin transactions much cheaper >and faster than ever before.

Why hasn’t BU been implemented so far?
It faces major opposition, the main argument is that BU would make Bitcoin more centralized.

Some people expect the abolition of the block size limit proposed by the Bitcoin Unlimited to lead to >uncontrolled Blockchain bloat. Currently, the size of the entire Blockchain exceeds 100 gigabytes and >that’s with three to seven transactions per second. Compare that with Visa’s limit of 24,000 transactions >per second and you will understand what’s the problem here.

It has been calculated that if the block size limit would be increased to the point sufficient for a global >audience, the Blockchain could grow to several petabytes, if not more.

That would lead to increased centralization of Bitcoin; only big companies would be able to afford the >?>storage space, computing power and bandwidth necessary to process such huge amounts of data, >phasing small-scale node operators out of the network. That runs contrary to the very idea of Bitcoin as the >money governed by each of its users.

Why hasn’t SegWit?
Same as above, mostly.

SegWit isn’t a perfectly decentralized solution either. On its own, it increases the block capacity to around >2 megabytes in the short run, and up to 4 megabytes overall. Depending on the future speed of the >network growth, it may be enough for several years or even decades.

However, sooner or later, the limit will be reached again, and the capacity will have to be increased. >SegWit’s long-term value lies in fixing the transaction malleability bug. That makes it possible to increase >the network’s throughput by running sidechain solutions like the Lightning Network and that is the >centralization.

Lightning Network can be roughly described as a mutual settlement system built on top of the Blockchain. >First, the Bitcoins of multiple users are deposited onto a separate payment channel via a regular Bitcoin >transaction, which takes about 10 minutes to confirm, or more, depending on the network congestion. After >that, all payments inside that payment channel are conducted off the Blockchain and are processed >instantly and very cheaply, or for free - by a trusted third party.

The moment all the members of a payment channel agree on the final distribution of Bitcoins, they can >send the net balance back onto the Blockchain, thereby letting the Bitcoin network confirm the validity of all >transactions.

The problem here is that for many members of the cryptocurrency community, there is no real distinction >between “a mutual settlement system maintained by a trusted third party” and banks, which are central >points of authority that Bitcoin was supposed to make obsolete.

Is this crisis going to be resolved soon?
Bitcoin is becoming less usable every day - for an ecosystem worth more than $17 bln, that is not a >situation which can continue for very long. It has to be resolved soon, one way or another.

Both sides of the SegWit vs. BU confrontation have arguments which describe the other solution as >seemingly irreconcilable with the core values of Bitcoin.

The conflict has not only technological but also a political basis. Both factions are claiming that the other >one is trying to prevent Bitcoin’s growth or take it under control. There are also theories around that insist >the opposite side is waging an information war, secretly funded by big money (Blockstream for SegWit and >Roger Ver for BU). Naturally, both sides would have you believe that their story is the ‘truest’ one.

Looking at the hard numbers, the whole situation seems to have ground to a stalemate. The final decision >will be made by the majority of the miners of the Bitcoin network. At the moment the distribution of their >support indicates no clear leader. SegWit looks like the favorite in the race but Bitcoin Unlimited has >managed to take over several times in the past.

At the moment, there is a large portion of the network - a little under 50 percent - which hasn’t expressed >explicit support for either of the proposals. It is possible that the final outlook will come down to them taking >a side. However, they may remain silent until the competing solutions resolve their dispute.

What if nobody backs down and the stalemate persists?
If no side takes a decisive lead, there is a possibility of reaching a compromise.

There is a third way, which isn’t impossible and which may potentially be the most beneficial to the >network. A block size limit increase and implementation of SegWit are not mutually exclusive by default, ?>and there is a growing sentiment in the community that a compromise between the two solutions might be >a way to go.

In fact, an agreement to compromise has already been reached, at least once. There was a roundtable >held in February 2016 in Hong Kong with representatives of Bitcoin Core, the authors of SegWit, and >several major mining companies, most of whom wanted an increased block size. Both sides seemed to >have reached an agreement - to move forward with SegWit, and implement a modest increase to the block >size limit, 2mb, at the same time.

Unfortunately, the Hong Kong agreement has not been followed through with - the Bitcoin Core devs have >not added a block size increase to the latest version of SegWit, and the miners have consequently refused >to adopt it.

But practice has shown that a consensus between the conflicting sides is possible and there is a solution >which could satisfy everyone. There is still hope that political confrontation will give way to cooperation, >and we will see Bitcoin grow more powerful than ever before.

UPDATE: this article was updated to correct an erroneous statement that SegWit did not increase the >block size limit directly.