Segregated Witness (SegWit) is an implemented protocol upgrade intended to provide protection from transaction malleability and increase block capacity.
SegWit separates the witness from the list of inputs. The witness contains data required to check transaction validity but is not required to determine transaction effects.
To truly understand how SegWit works, we will focus on two distinct concepts: block weight and soft forks.
Bitcoin block size and forks
To talk accurately about block sizes, it’s important to understand how block size is measured. Block size is simply the size in bytes of the serialised block (the block header, number of transactions, and the transactions themselves).
As part of the consensus rules, every node on the Bitcoin network currently checks to make sure that a block is less than 1,000,000 bytes. A block that’s greater than 1,000,000 bytes will be rejected by these nodes as a consensus rule.
Because legacy nodes (nodes that don’t upgrade) will reject a block that’s greater than 1,000,000 bytes, any soft fork must keep this rule. But how can you increase block size and still keep this rule? Are larger blocks via a soft fork even possible?
The key insight is that a large part of the transaction, the scriptSig (public key), can essentially not be sent to legacy nodes for a transaction to be counted as valid. The fact that this can be done as a soft fork and allow for more transactions is an engineering breakthrough.
Non-SegWit transactions put the scriptSig in the middle of the transaction. SegWit transactions put the scriptSig at the end. The scriptSig part of SegWit transactions is called the “witness data”. When SegWit transactions are sent to legacy nodes, the witness data is stripped. The key is that these “stripped” transactions are still valid transactions on legacy nodes, which gives us a space saving over non-SegWit transactions. Therefore, more transactions can fit into the block sent to legacy nodes without going over the 1,000,000 byte limit.
SegWit nodes receive SegWit transactions and blocks that include the witness data using alternate network messages. The SegWit blocks that include the witness data can be over 1,000,000 bytes. Legacy nodes, as mentioned, receive the same blocks and transactions, but with the witness data stripped. This is a way to make SegWit a soft fork, meaning it’s not mandatory to update your software in order to participate in consensus.
SegWit and block weight
An obvious problem to a SegWit critic would be the fact there needs to be an upper limit, otherwise block size could potentially escalate indefinitely – which is a huge problem for nodes’ fault tolerance.
To restrict SegWit blocks, the creators of SegWit instead came up with a different restriction other than size. The SegWit blocks are restricted by something called block weight. Block weight is a new concept introduced in SegWit, and it’s calculated on a per-transaction basis. In essence, each transaction has a “weight”.
Transactions that have zero witness data are lighter than those with witness data. Note that SegWit transactions are transmitted to legacy nodes without witness data, so this will always result in blocks communicated to legacy nodes that are less than or equal to 1,000,000 bytes.
A key concept to understand is that SegWit transactions can have many different weights depending on how much of the transaction is taken up by witness data, which gives transaction creators much more room to play around with transaction malleability.
Disclaimer: The views and opinions expressed by the author should not be considered as financial advice. We do not give advice on financial products.