Scaling Bitcoin: the block size debate and importance of August 1st

Hello Reader,

In my recent article on Bitcoin fees, I explained that the cost of sending a bitcoin transaction has soared in recent times.

The reason behind this lies at the heart of a fundamental debate which has split the Bitcoin community over the last few years.

Read on as we look into the challenges of scaling Bitcoin...

Block size

When Bitcoin first launched, the size of each block was at the discretion of each miner. However, early on in the life of Bitcoin, a maximum value was placed on the size of each block, known as the block size. This was set at 1MB to prevent denial of service spam attacks, and became enshrined in Bitcoin’s code.

The effect of this maximum size is to limit the number of transactions which can be included in each block. As there are only approximately six blocks per hour, this limits the transaction throughput of the bitcoin network to roughly 7 transactions per second. For context, credit card networks such as Visa and Mastercard process thousands of transactions per second. However it's worth noting that these are effectively equivalent of an unconfirmed bitcoin transaction as these networks often revise and reject transactions further down the line.

Over the last few years, the number of users and the amount of transactions per user has increased dramatically. However, the throughput of the Bitcoin network has remained static, limited by the unchanging block size.

Like most things in life, the law of supply and demand has come into effect and there are now more transactions than can be included in each block. Those transactions with higher fees get processed first and so the fee market economy has led to a dramatic increase in fees.

In the grand scheme of time, Bitcoin is still an infant. If it wishes to emerge as a major player in the global financial system, then it will need to be scaled to handle a greater number of transactions per second.

What are the options?

Increase the block size

To most naive observers, the answer to scaling Bitcoin appears simple, just increase the block size. However, the truth is more nuanced.

The effect of this solution is immediate, with larger blocks, more transactions could fit in each block and therefore the network would have a greater overall throughput.

However, this has another side effect, it reduces the amount of decentralisation in the system.

Why is this the case?

Larger blocks require more disk space to store, more processing power to compute and more bandwidth to transmit. Therefore smaller node operators become increasingly discouraged from operating as the block size grows and it becomes less practical and more expensive to run a node.

Proponents of this method, such as some of the early Bitcoin developers, Gavin Andreson and Jeff Garzik, argue that the immediate practical threat of the decreased utility of the network outstrips this concern and so the block size should be increased immediately.

Leave the block size as is

Another option is to leave the block size alone, and accept the reduced utility of the network as an unavoidable component of a decentralised digital currency.

This argument effectively relegates bitcoin from being a low cost currency for the masses, to a premium settlement solution and store of value.Whilst this is still of value to the world, it's fair to say it doesn't live up to the early vision of the future that Bitcoin initially promised.

Segregated Witness

You may have come across the term SegWit whilst learning about Bitcoin. The term is a contraction of Segregated Witness and is a Bitcoin Improvement Proposal (or BIP) created by Dr. Pieter Wuille which alters the structure of bitcoin transactions.

Bitcoin transactions include both transaction data, which contains the inputs and outputs of the transaction and signature data, which contains the proof that input addresses are valid. SegWit restructures Bitcoin transactions and moves the signature data, known as witness data, away from input data.

SegWit updates the 1MB block size limit to a 4MB block weight limit. Each byte of witness data is treated as being 0.25 bytes towards the block size limit of 1MB. Standard input/output core data continues to be treated as 1 byte = 1 byte. Therefore SegWit does not actually make blocks smaller, but instead introduces a discount to how witness data is counted towards to the overall block size limit.

The benefit of SegWit is that this restructuring of transactions allows more transactions to be fit within each block and therefore the throughput of Bitcoin is increased. SegWit blocks are however larger than current Bitcoin blocks.

Transaction malleability

Another benefit of segregated witness is that it fixes a current issue with Bitcoin, known as transaction malleability.A malicious attacker intercepts broadcast transactions before they are confirmed and then modifies the transaction ID (known as a hash). The altered transaction is then rebroadcast to the network and in some cases the modified transaction is confirmed before the original. Whilst the intended transfer of bitcoins will still take place, this can act to confuse certain automated processes which rely on unchanging transaction ID's such as those used by early exchanges. This issue was cited as major reason for the infamous loss of funds by Mt Gox, although this is disputed and the subject of it's own debate.

This attack is possible because the witness data is currently included with the input data when generating transaction hashes. By segregating the witness data it will no longer be possible to modify transaction hashes and the issue will be resolved.

This is a relatively minor bug for the current implementation of Bitcoin as all reputable exchanges have implemented fixes. However, it is a more serious concern for second layer payment solutions which depend on transaction ID's being unchanged to improve efficiency and provide greater security. We will take a look at exactly what these are later in the article.

Activation of SegWit

SegWit has already been implemented in the latest version of the Bitcoin Core software as a soft fork.

A soft fork is an update of the bitcoin software which does not break backwards compatibility for existing software. In this case, Bitcoin nodes which have been upgraded to support SegWit blocks will still continue to accept and support classic blocks. This means that users aren't forced to update to be able to continue to use the network.

However, there is a mechanism within the software that prevents SegWit from activating until 95% of the mining hash power of the network is signalling that they are running the software.

This is in place to enable the safest possible deployment of SegWit and is designed to avoid a hard fork of the Bitcoin network.A hard fork happens where bitcoin software is updated and breaks backwards compatibility. In this case, Bitcoin nodes which have been updated would no longer accept traditional blocks.In the case of a hard fork, a chain split would be likely to occur where there would be a chain of the classic Bitcoin software and another chain running the updated software.

The current level of support for SegWit is significantly below the required 95% threshold and so it looks unlikely to activate via this method anytime soon.

The reasons for the split in opinion on SegWit and lack of activation are manifold. Whilst many technically proficient Bitcoin developers on both sides of the debate agree with the robustness of SegWit, there are also political and ideological objections.

It's worth pointing out that SegWit has recently been implemented and activated on Litecoin and so far has run without issue. This was possible as Litecoin is a derivative of Bitcoin and the Litecoin community is not quite as divided as the Bitcoin community. This still wasn't an easy task, the update proved contentious and it took a user activated soft fork to implement. More on this later.

Implement off chain scaling using payment channels

The third option is to introduce a more fundamental change to the Bitcoin network and enable payment channels which operate outside of the main blockchain.In this approach, the majority of low cost transactions would be conducted through separate payment channels. These channels would be opened between a number of parties for a period of time with many low cost high speed transactions conducted between those parties.

Whenever desired, the channel can be closed and the final state of transactions is broadcast back to the main bitcoin blockchain.

The advantage of this method is that only the initial channel opening and final channel closing are included on the main blockchain and so the pressure on the network is greatly reduced. Transactions within the off chain channels are trustless and processed at high speed.

There are however several perceived disadvantages of payment channels.The first is that the technology is still in the process of being developed and throughly tested. As a result it can't be immediately deployed on the network with absolute confidence so this solution is still some time away from being realised.

The second is the problem of transaction malleability which must be solved before payment channels can be safely implemented. Given that SegWit is currently the only realistic solution to this problem, it effectively becomes a prerequisite of payment channels.The highest profile example of a second layer payment channel is the Lightning Network.

Significant Upcoming Events

BIP 148 - A user activated soft fork on August 1st

BIP148 has been prepared by the community and is now supported by the Bitcoin Core developers despite initial skepticism. It involves a user activated soft fork or UASF.

Currently miners have effective control over the network rather than users. A UASF flips this on it's head and instead tries to force miners to a course of action. Any node which updates to BIP148 software will reject any blocks which do not signal SegWit support after August 1st.

If enough users adopt BIP148 (and by extension major wallet providers and exchanges) then miners will face massive economic pressure to adopt SegWit or face their mined blocks becoming less valuable.As a result, August 1st is being seen as a critical date in Bitcoin's history as one of three outcomes can happen.

In the first scenario, enough users switch to BIP148, the UASF is successful and miners are encouraged to update to BIP148 and signal SegWit to maintain their economic reward. SegWit will then be activated in the near future.In the second scenario, too few users switch to BIP148 and the UASF fails to encourage miners to update. As a result, users who updated will need to revert their software and the Bitcoin network will continue as current without SegWit activating. This is unlikely to appease those who support BIP148 and so a future hard fork would look likely.

In the third scenario, there is no consensus and so the Bitcoin blockchain splits in two. The original chain continues without SegWit activation and a new chain continues with SegWit activation. All transactions leading up to August 1st remain valid on both chains, but thereafter transactions will only be valid on one or the other.

If you have bitcoins before this date and you control the private keys, you will have the same bitcoins on both chains after the chain split. If you do not control the private keys (e.g. because your bitcoins are held on an exchange) then there is no guarantee that you will get bitcoins on both chains.

SegWit2x

The main difficulty in arriving at a scaling solution for Bitcoin has been the stalemate between those who want larger blocks and those who prefer SegWit and second layer payment channels.

SegWit2x is an alternative to BIP148 which looks to address this stalemate by way of a compromise. SegWit2x has been developed by Jeff Garzik, it first enables activation of SegWit and then enforces an increase in the block size limit to 2MB. This block size increase happens 3 months after SegWit is activated on the network provided SegWit2x gains 80% of mining hash rate support. As this includes both SegWit and an increase to the block size limit, it is equivalent to an increase in block size of between 4-8MB.

Similar proposals have been made before, but the unique element of Segwit2x so far has been that it appears to have garnered widespread miner support with more than 80% of mining hashing power signalling that they will run the software. The proposal is currently still opposed by a number of parties, including Bitcoin Core.

The current timeline for Segwit2x suggests that support for SegWit will be locked in by August which would mean that a hard fork of Bitcoin would happen 3 months later in November. As it's unlikely that SegWit2x will receive completely unanimous support, it is probable that a chain split would occur.

Conclusions

This is a complex and fast moving topic so I will update this article as events progress.

It remains to be seen whether BIP148 or SegWit2X will become the driving force behind resolution of the scaling debate but it looks highly probable that one of them will.

This post is as an exploration of the factors involved in the block size debate and is not intended as an indication of my support for either side. Quite simply I haven't yet made up my mind. I see merits and flaws with both sides of the debate and so will continue to observe and expand my own understanding before stating a preference.

It is impossible to predict which outcome is most likely, but it can be said with confidence that Bitcoin faces a turbulent period in the coming months. The main issue with this turbulence is that it creates uncertainty and uncertainty tends to create downward pressure on the price of Bitcoin.

You will need to be confident in the long term viability of the Bitcoin network and if you aren't you should significantly reduce any Bitcoin holdings you presently have well before the end of July.

Until next time my friends.

If you’ve enjoyed this article, it would be my honour to have you as a regular reader.

Yours, X

He's a nosey fella...

Sources

Content: Xexr.com

Image: Wikimedia