Abstract: SegWit replaces the old 1MB blocksize limit, with a new more complicated 4 million unit blockweight limit. This should double the transaction throughput of the network, but only after wallets upgrade to send new SegWit style transactions. This piece analyzes how the network throughput could increase, as users gradually upgrade to SegWit
Overview of the capacity increase
Segregated Witness is an upgrade to the Bitcoin protocol, which may increase the level of transaction throughput. In order to benefit from increased transaction throughput, users need to upgrade to the new transaction format. This may make the throughput increase slow and gradual. Although those that do upgrade, may experience the benefit of a reduction in transaction fees reasonably quickly.
Higher transaction throughput is achieved by replacing the old blocksize limit, with a new blockweight limit. The old 1MB blocksize limit (shown below), has been removed from the code:
MAX_BLOCK_BASE_SIZE = 1000000;
The new, more complex, blockweight limit is determined by the following formula:
4 * non witness data (in bytes) + witness data (in bytes) < 4 million units
This new limit should approximately double the transaction throughput of the network, once users and businesses upgrade to the new transaction format. Miners trying to maximize transaction fee revenue, will attempt to include as many transactions as they can, with blockweight being the new limiting factor.
What is the witness data?
The witness data is the digital signature, authorizing the spend of the payment. The below diagrams attempt to illustrate the transaction structure before and after SegWit. The witness data can take up around 54% of the data in a typical transaction and is represented in the green rectangles in the 2nd diagram below.
Pre SegWit – Illustrative transaction structure (percentage data usage)
SegWit – Illustrative transaction structure (percentage data usage)
Fixing third party transaction malleability
It is often mentioned that SegWit “splits” the witness and non witness data up, into two separate places. This is not really true, the witness and non witness data still exists together. As the diagram above illustrates, the key difference with SegWit is that the witness data is no longer needed when calculating the transaction ID (TXID), which is later used to spend the funds in the next transaction.
This is the solution to the third party transaction malleability problem. If the signature changes, from one valid signature to another valid signature, the transaction ID remains the same. Therefore it is reasonably safe for transaction 2 to be created and broadcast to the network, before transaction 1 has been confirmed in the blockchain. This should improve the user experience, as there is now less need for users to wait for confirmations, which can be slow.
The throughput benefits of upgrading to SegWit style transactions for individual users
Assuming the witness data makes up 54% of transaction space, when one upgrades to SegWit, transactions should take up around 41% less blockweight than old style transactions, as the following formula illustrates:
Therefore, assuming fee market conditions are unchanged (i.e. transaction fee levels are the same as before SegWit), by upgrading to SegWit, the user should benefit by paying 41% lower fees than before. This benefit occurs before other users upgrade to SegWit.
Users who do not upgrade to SegWit, should pay the same fee levels as before. However, there is a theoretical “side benefit” which they may experience, caused by other users freeing up space by using SegWit. This may improve fee market conditions and result in lower fees, even for users that have not upgraded to SegWit. Estimating the magnitude of this so called “side benefit” is almost impossible, since it depends on fee market conditions.
The throughput benefits of SegWit on the entire network
Below we analyse what the network throughput dynamics could look like, if users and businesses decide to opt in to SegWit style transactions, such that there are high adoption levels.
The chart below compares how the blockweight and blocksize could vary, as the amount of witness data in a block increases. The left hand side of the chart illustrates low levels of SegWit adoption (where we are now), whilst as we move to the right, higher adoption rates are assumed.
If we achieve high adoption rates, the blocksize may be around 2MB, consisting of 1.3MB of witness data and 0.7MB of non witness data. The block weight would be 4 million units. This would mean the throughput of the network increases by around 100%.
Blockspace dynamics assuming “normal” SegWit usage
Theoretical blocksize problems
Sceptics of SegWit often mention some problems. A common claim is that:
SegWit enables 4MB blocks, with only 1MB of transactions
Perhaps the people who are making this claim are visualizing something similar to the below chart. This chart is similar to the one above, except instead of assuming “normal” transaction patterns, we assume the block weight remains at 4 million units, while the witness data grows to 4MB.
On the right hand side, the chart shows that a block could theoretically be 4MB in size (containing only witness data), which a spammer could produce for the same fees as producing a 1MB block (containing only non-witness data). Since both blocks contain 4 million units of weight.
Blockspace dynamics when blocks always contain 4 million units of weight
It is true that a spammer could produce such a 4MB block, which would cost the same in fees as a 1MB block. This is a potential problem.
However, this is not a change to the security properties of the system, because the 4MB block is not cheaper than the 1MB block, it merely costs the same. A spammer can always outbid legitimate users, regardless of SegWit. Indeed an attacker could simply produce 1MB of non-witness data, to compete with “legitimate” users, and this attack vector is no cheaper than before. SegWit does not and cannot change the security dynamic, that if an attacker wants to outbid users with spam data, they can.
There is still a potential problem here. There is now a “worst case” block of 4MB, even though the expected capacity benefit may only be slightly more than 2x the old 1MB limit, rather than 4x.
There is some merit to this criticism of SegWit. However, due to the scaling properties of the witness data, the situation may not be as bad as one would think. In some ways the witness data has better scalability characteristics than the non-witness data.
We discuss some of these characteristics below:
- Signature verification: SegWit mitigates the quadratic hashing of sighash operations problem, by changing the calculation of the transaction hash for signatures so that each byte of a transaction only needs to be hashed at most twice. Therefore a block containing a large amount of witness data, will have a large amount of data with this linear hashing characteristic, reducing potential signature verification times and improving scalability.
- The impact on the database on unspent transaction outputs (UTXO): The witness data relates to signatures for transaction inputs. If one wants to create new transaction outputs, this would not be included in the witness data. Therefore a theoretical 4MB block contains no new outputs. A large block block therefore has a neutral or even positive impact on the size of the UTXO set.
- Long term storage costs: The worst case 4MB blocks can have a negative impact on long term storage costs. However, when segregating the witness, the witness is no longer used in the calculation of the the transaction ID (TXID). This means one can calculate the TXIDs, the merkle root hash and block hashes, without the witness data. All one needs is the witness commitment and the block hash can be calculated without the witness data. A wallet can therefore get “proof of work (PoW) assurance” over the security of payments, while discarding the witness data. Although if one wants to verify all the witness data on restart of the node, the witness data must be stored.
- Block propagation/latency: In the worst case scenario, these theoretical 4MB blocks will have inferior propagation characteristics. However, technologies such has compact blocks have mitigated some of these risks. Although the recent apparent crackdown in China may illustrate that this is a potentially serious problem.
- Bandwidth: 4MB blocks could increase the bandwidth burden on nodes/wallets, compared to 1MB blocks of non witness data. This is therefore a potential disadvantage to these larger blocks. Although, perhaps some light wallets could only download the witness data for their own transactions, they would therefore never need to download the rest of the witness data, but they could still link the block hashes to the transactions and therefore obtain “PoW assurance” over the payments and wallet balances.