SegWit (Segregated Witness) 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.
There are 3 key elements in transactions. 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 format of a transaction.
This means 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.
The most evident benefit of SegWit is a capacity increased that is introduced in the form of a different transaction format. However, there are also other benefits of SegWit: increased security for multi signature transactions, linear scaling of sighash operations, script versioning and more.
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. Although these can already be implemented in Bitcoin, they are risky because transactions can be changed (because of the malleability problem). This can make transactions get stuck. This is because these payment channels like Lightning Network rely on spending previous transactions that are referenced by their txid.
Moreover, other bug fixes are also useful for Lightning Network like the increased multisig transactions and a bigger block size limit.
This is one of the reasons some miners and mining pool operators don’t like SegWit. Transactions that go through this payment channels are not part of the Bitcoin network, and this means that their fees will not go to miners.
SegWit activation requires a 95% miner approval. 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 is not strictly necessary, it minimizes the risk of future forks or double spends after SegWit activation.
