Understanding Block Weight: How much Capacity does SegWit really Give?

With SegWit2x we’ll soon experience the activation of SegWit. Block size will be replaced by block weight, transactions capacity will be increased, and fees will fall. But how exactly and to what scope is not an easy question.

In recent weeks the public argument shifted from the question, if SegWit should be activated, to the question of how and when it is done. SegWit2x, an alliance of miners and companies, wants to enforce SegWit and a 2MB hard fork. Other than initially expected, in the first alpha release, the SegWit-activation comes with as much compatibility as possible. It also supports the existing SegWit deployments in Core since 0.13.1 and even UASF-nodes.

An alliance of 80 percent of the ecosystem, both miners and platforms, will activate SegWit – earlier than August 1. You could say that the UASF movement achieved its goal.

But, how exactly does SegWit increase capacity? Sometimes it is said, SegWit is a “2MB soft fork,” sometimes even a “4MB soft fork”, but at the same time it is said that SegWit only gives 1.5 or 1.8MB capacity.

Well, what is it? How does SegWit create the long wanted increase of transaction capacity, and why is it so hard to quantify it?

From Size to Weight

The first thing to know is that SegWit introduces a new transaction format. In SegWit-transactions, signatures are put in an extra space. Old nodes only see placeholders, while nodes upgraded to SegWit are still able to see and validate the signatures. This has several advantages, like that it eliminates transaction malleability and quadratic hashing. But that’s not what we are heading for. Here we care about capacity.

In this regard, it is important to know that signatures use roughly 60 percent of transaction space. So if old nodes, which enforce a 1MB block size limit, can keep on with 40 percent of the needed data, the capacity of the network as a whole will increase significantly. Sure.

The second thing you need to know is that the SegWit nodes and the miners replace block size with “block weight.” The calculation of the weight is a bit more complicated than the simple “block size = 1MB.” The miners now need to build blocks which do not violate the following condition:

4 * Non-Segwit-Data + 1 * SegWit-Data <= 4000 Kilobyte

Let’s have a closer look at it. What does it mean? First, we take the so-called “non SegWit data.” This is everything that is not in the SegWit-extra-space; ID, sender, recipient, amount, old style signatures. The size of this data is multiplied by four. Then we add the SegWit signature packet, but just one time. The result must not be bigger than 4MB.

This discount on SegWit data has several reasons. It is somehow needed, to make SegWit a soft fork, and it engages users to behave more sustainable for network scalability. SegWit data can be pruned very easily, which means that you delete it from the blockchain, while non SegWit-data is harder to prune.

There is much you can discuss about the discount. But here we ask about the capacity SegWit gives. How can we transform block weight back to block size?

… And Back to Size Again

For non-developers and non-mathematicians, it is not that easy to find the path from the block weight back to the block size. You have to create some calculations to end with a number of kilobyte of transaction which can be put in a SegWit block.

Most importantly, two variables are needed; first, you need to know how many percent of all transactions are SegWit (m). That’s the hardest question. Next, you need to know how many percent of block space signatures consume (n). This is relatively easy to find out.

If you take these variables and the block weight formula and juggle a bit with it, you’ll find a path to calculate the real block size. BTCManager wrote an easy to understand JavaScript which simulates SegWit capacity with different variables. We asked computer scientist and Bitcoin expert Jochen Hoenicke to review the formula. He made it easier and corrected a minor detail.

If you browse the results, you see capacity increases with growing m and n. As expected. Let’s dive into the results.

What we Know and What we Cannot Know

First, we need to touch what we don’t know for sure. The questions for the share of signatures in block space is relatively easy to answer. According to Jochen Hoenicke, who made a list with the signature share in all blocks since Genesis, signatures use 60 to 63 percent of block space. This rate is relatively stable for two years. So, n = 60/65.

More complex is the question if SegWit transactions need 10 percent more space than old transactions. In the current deployment, SegWit uses so-called “nested P2SH” addresses, which indeed need 10 percent more block space. For the future, however, native SegWit addresses are planned, which need no extra space. For our simulation, we mostly used the current address format.

The most crucial factor is the SegWit adoption rate m. Here we have no data, and it is impossible to quantify, how much time the ecosystem needs to adopt a new transaction format. Getting a hard number is impossible. It’s only possible to make a rough estimation for a scope of possible outcomes.

How is SegWit Adopted by the Bitcoin Network?

Usually, the capacity bonus of SegWit is nominated as a “2MB soft fork.” This estimation is, if at all, valid if every transaction sent uses SegWit with the native format. What has to happen that SegWit gets an adoption rate of 100 percent?

Basically, the whole UTXO set has to be transformed. Every input or coin on the Bitcoin blockchain has to be sent from the old address to a new SegWit address. Only after this, a transaction can create more capacity by outsourcing the signatures. Currently, the UTXO set consists of 50 million inputs or roughly 2GB space. A complete transformation would need Bitcoin’s whole transaction processing capacity of two weeks.

You can assume, that this will not happen in a night and probably never reach 100 percent. In the first six months, however, SegWit will release its capacity bonus gradually.

Estimating the Real Sizes

How much time, until significant parts of the UTXO are transformed? How much capacity can be expected in six months? We cannot give a concrete number. All we can do is to outline two arguments which might favor a scope of 40 to 80 percent in six months:

• If we take the good old Pareto principle, 20 percent of everything accounts for 80 percent of everything. 20 percent of the businesses might contribute to 80 percent of transactions. If big platforms, like Coinbase, BitPay, Bitcoin.de and BitStamp adopt SegWit, it could easily reach a support of 80 percent.
• Sure. Right now there is no easy to use method to build SegWit transactions. But the big companies will be able to implement it and to start the transformation. Depending on the number of inputs they manage and their system, they however, could need some time to get completely rid of the old transactions.
• The transformation in user wallets is less easy. Nearly all current wallets lack an interface to use SegWit. If this is implemented, the upgrade is only for users of updated wallets and, even then, likely problematic, as it sometimes needs to replace the whole wallet. In this sector, adoption rate might be quite low in six months.

After all, we can assume, that SegWit adoption half a year after activation will be, at best, 85 percent, and, at worst, lower than 50 percent. The capacity of a block will be 1.25MB with 50 percent and 1.45MB with 85 percent.

This size will further increase after six months. If the native SegWit addresses are used, and the adoption reaches 90 to 95 percent, a block size of up to 1.8MB is possible.