We have already covered the Block size limit and the debate that has been revolving around this issue for years - Read more here. We have also covered one of the scaling solutions that has been put forward, Bitcoin Unlimited. Now it’s time to talk about SegWit, the scaling solution proposed by the Bitcoin Core development team
What is SegWit
SegWit is short for segregated witnesses and it is a proposal presented by the Bitcoin Core team. It comes in the form of a soft fork, a forward compatible upgrade that can work even if some users don’t update their software (without resulting in a chain split). It was released on the 0.13.1 version of Bitcoin Core client.
In transactions there are three key elements. The sender, receiver and the signatures (commonly referred to as witnesses) and these make up a big part of the transaction size. Contrary to popular belief, however, SegWit does not seperate this witness data into a “witness block”.
Instead, Segwit updates the 1MB block size limit into a 4 million unit block weight limit, counting serialised witness data as one unit and core block data as four units. It essentially introduces a new transaction format.
What this means is that the block size is actually increased. SegWit counts each byte in a witness as 0.25 bytes towards the maximum block size limit (1MB), meaning the maximum size of a block becomes just under 4MB. This doesn’t mean that the data gets smaller, it simply means that it is counted in a way that allows for the 1MB limit to be increased. This change, however, only affects witness data and each non-witness byte is still counted as 1 byte towards the maximum block size limit (1MB) or as 4 units towards a maximum block weight of 4M units.
Bitcoin Core:
“As transactions that use segwit features begin to be used, this change will allow more data to be included per block (with 100% of transactions using segwit features this is expected to be about 2MB of data per block, however in the worst case could be up to 4MB of data per block). In so far as it allows a greater transaction volume, it can be expected to increase the UTXO database more quickly (with 100% of transactions using segwit features, the rate of increase might be expected to approximately double; however because segwit is a soft fork, the worst case UTXO growth is unchanged).”
Other benefits
The most evident benefit to SegWit is a capacity increased that is introduced in the form of a different transaction format. However, there are also other benefits to SegWit, which are outlined here. This includes increased security for multi signature transactions, linear scaling of sighash operations, script versioning and more.
However, fixing transaction malleability issues is the most important of these. Transaction malleability exists because the signatures that protect the rest of the transaction from being modified cannot protect themselves. This means that the way the transaction id (txid) is calculated allows anyone to make changes to this same transaction id.
SegWit fixes this by removing the signatures from the transaction id data, making it impossible for anyone to change the signature data (that was previously in the txid). With SegWit, the txid is then calculated from data that cannot be changed.
The transaction malleability fix also paves the way for payment channels like the Lightning Network (LN). Although these can already be implemented in Bitcoin, they are risky because transactions can be changed (due to the malleability problem mentioned above). This can make transactions get stuck. This is because these payment channels like LN rely on spending previous transactions that are referenced by their txid.
Furthermore, other bug fixes are also useful for LN like the increased multisig transactions and a bigger block size limit.
This is one of the reasons some miners and mining pool operators dislike SegWit. Transactions that go through this payment channels are not part of the Bitcoin network, which means that their fees will not go to miners.
Activation
In order for SegWit to be activated, it requires a 95% miner approva. The voting is done by miners that include certain data in the blocks they mine to signal their decision regarding the proposal. The 95% threshold is based on the BIP 34 (supermajority) softfork activation method, which stipulates the required 95%. Although this wouldn’t be strictly necessary, it minimizes the risk of future forks or double spends after SegWit activation.