The Segwit update explained

There is a high probability that Bitcoin users will come across the term Segwit sooner or later. Whether when choosing the address format, discussing the block size or simply cheaper transaction fees - there's no getting around the Segregated Witness Update, which was activated in the Bitcoin network on August 24, 2017, exactly seven years ago.

But how does this update work and, above all, what was it all about? Why do you pay less fees for "Segwit transactions" and what are the strange "virtual sizes" all about? We answer all these questions and more in this detailed birthday article about one of the most important Bitcoin updates ever.

In 2017, the Bitcoin world was still a different place. The long-standing discussion about increasing the maximum block size and the general question of how and whether the Bitcoin network could scale in the future divided the community into two heated camps. While the proponents of increasing the block size were convinced that there was no other way for Bitcoin to establish itself as a functioning means of payment, the small blockers took a more cautious approach and, in addition to the actual question of block size, also gave a lot of legitimate thought to how such a critical intervention in the Bitcoin protocol should be securely implemented and, above all, activated.

Bitcoin developers Peter Wuille, Johnson Lau and Eric Lombrozo proposed an elegant compromise with Segwit. Firstly, because they tried to accommodate the large blockers with an indirectly increased block size and secondly, because they were able to achieve a few other improvements and kill several birds with one stone. All this with the help of a soft fork, i.e. a restriction of the rules, which is the method of first choice, especially with such a controversial rule change.

But what is the point of all this? The outsourcing of data from the actual block initially results in an obvious change: an increase in the maximum block size. Although the official limit of 1 MB remains in place, more transactions suddenly fit into one block, as a relatively large proportion of the transaction data has been outsourced.

However, the size of this new Witness tag is of course not unlimited. To put it simply, the maximum block size has been increased from 1 MB to 4 MB, but in practice this is not really correct in the vast majority of cases(with a few exceptions). If you take a look around with a block explorer, you will quickly notice that although most blocks are full, they vary in size and are still quite far from 4 MB. To understand this variability in block sizes, we need to look at how the size of a transaction has been calculated since the Segwit update.

Segwit introduced a new unit for determining the size of a transaction: the weight. It is calculated from the actual size of the outsourced data in the witness and the data in the "normal" part of the block, but with a special feature: the latter is weighted by a factor of four, while the size of the data in the witness is simply added to it. Ten bytes in the normal block and one byte in the witness become 41 weight units (WU), i.e. "weight units" that are simply redefined in this way. One byte in the normal block and 10 bytes in the Witness result in only 14 such weight units. It quickly becomes clear that data in the Witness is much "cheaper" as it contributes less to the total weight. However, it is important to understand that this reduction has nothing to do with the actual raw data that has to be stored on a hard disk at the end of the day. It is a completely constructed unit to represent the additional storage space gained, especially in terms of transaction fees incurred.

For this reason, most Bitcoin blocks are around 2 MB in size and vary greatly in their actual size, as this always depends on the distribution of data inside and outside the Witness.

Another unit that is difficult to ignore, especially when creating a Bitcoin transaction, is the so-called virtual size. A rather confusing and abstract name, but one that can be explained quite easily with the knowledge from the previous paragraph.

A virtual byte (1 vB) simply corresponds to 4 weight units (4 WU). It is therefore the weight divided by four. The purpose of this unit is to approximate the conventional size specification in bytes, but with the addition that the additional memory space of the swapped-out witness is already taken into account. The size in virtual bytes therefore has nothing to do with the actual size in bytes, but is used to better classify the transaction fees (in sat/vB) and is also used for precisely this purpose in practice. Since a block explorer is generally always used in the context of transaction fees, you will almost exclusively come into contact with this unit.

Before the activation of Segwit, Bitcoin transactions had a property that would have caused problems, especially in more complex use cases such as the Lightning Network. Transaction malleability generally refers to the ability to manipulate a transaction without violating its validity. This was still possible before 2017, albeit to a limited extent, including through minor changes to digital signatures.

Each transaction can be uniquely identified by its transaction ID (TXID). This is nothing more than a hash value of the transaction itself in order to always generate a completely new fingerprint, even with the smallest changes. So if a tiny detail in the transaction is changed without violating the digital signature, a new TXID is created, while the transaction itself remains valid. This behavior leads to problems precisely when you have to rely on the immutability of this TXID, for example in the security model of a payment channel in the Lightning network.

The signature data outsourced with Segwit, on the other hand, is no longer included in the calculation of the classic TXID; after all, it is "somewhere else" and can therefore no longer be manipulatively exploited to change the ID of a transaction. As long as a transaction only outputs Segwit outputs, the problem is eliminated and many use cases open up.

In addition to what is probably the most important aspect of transaction malleability, the Segwit update brings several other advantages, including

• Scalability: the witness data often makes up the largest part of a transaction, but once it has been verified, it is no longer relevant. The clean separation from the rest of the transaction data means that Bitcoin nodes can simply discard the data in the Witness or only request it separately from other participants in the network, thus saving space and resources.
• More efficient verification: With Segwit, the functions for verifying digital signatures have been significantly improved and are many times less complex. Bitcoin nodes are thus relieved in another aspect.
• Future-proofing: The Bitcoin script language has been versioned with Segwit, meaning that it can be continuously updated in the future without causing compatibility problems with previous versions. The flagship example of this is the Taproot update, which has been active since November 2021.