Robert Steinadler, a year ago
Some of our readers might have noticed that there are different types of Bitcoin address formats. Segregated witness was a protocol upgrade that has been deployed by a soft fork on the Bitcoin network in 2017 and ever since there are three different types of formats.
What is the benefit of segregated witness? Why is it important and how does it work? In this article, we are going to explain what SegWit is.
The birth of segregated witness requires a little history lesson in Bitcoin. Bitcoins original protocol allowed the creation of a new block every ten minutes on average and each block had a predetermined size of 1 megabyte. The block size limits the space for transactions and therefore Bitcoins scalability. Starting somewhere in the year 2015 the Bitcoin community began to discuss how to scale Bitcoin so that the network could handle more transactions.
One approach was to drastically increase the block size which would simply allow more transactions per block by increasing space. Another one was to rearrange the information that was included in each block and make more space by containing less data that is not immediately needed to be included for transactions to happen. It is worth mentioning that up until this day there is still a discussion if SegWit was a good idea and whether an increased block size is a better solution. Historically this debate led to the Bitcoin Cash fork creating a new cryptocurrency with Bitcoin implementing segregated witness and Bitcoin Cash opting for drastically larger block size.
Another important issue that is often overseen because scalability seems to be the most pressing problem is the prevention of transaction malleability. Before SegWit was active it was possible for a node to change the transaction hash of an unconfirmed transaction.
This is extremely problematic especially if the receiving party is dependent on the reliability of a chain of unconfirmed transactions. By changing the hash of the first transaction it is not invalidated but the next transaction in the chain relies on a hash that has been changed. Therefore, all the following transactions are going to fail and are considered to be invalid because they are referring to the wrong TX ID.
Manipulating transaction IDs opens the door for all kinds of fraud. But even more important, this is absolutely unacceptable if you are looking to use a second layer solution on top of Bitcoin like the Lightning Network.
The SegWit protocol upgrade segregated transaction data from the digital signature of the transaction witness. The block size was effectively increased up to 4 megabytes while being compatible with the original Bitcoin protocol.
Originally each legacy block contained the output and the input of the transactions as well as the signatures and additionally scripts. SegWit blocks are in fact larger and structured differently. By segregating the signatures and the scripts, there is a base block that is also called transaction block, which is still considered to be valid according to the old protocol. It contains in- and outputs and does not exceed the 1 megabyte limit.
The extended block on the other hand is larger and contains up to 3 megabytes of data. Namely signatures and script. This structure allows SegWit to be backward compatible, meaning that nobody has to use it while it offers great benefits in doing so at the same time. It also allowed SegWit to be implemented as a soft fork instead of requiring a hard fork that would have been more stressful and could have put the network at the risk of a split.
With the legacy blocks being measured in size there was also an update of how transactions are measured. SegWit blocks are not measured in size but in weight. Instead of measuring each block in megabytes (size), it is measured in weight units. One SegWit block has a weight of 4 million WU (weight units) which equals 4 megabytes of data.
The formula for calculating the weight of a SegWit transaction is:
(Transaction size - Witness data) * 3 + Full transaction size
The weight of a legacy transaction is calculated differently:
Transaction size * 4
In effect, SegWit transactions are always lighter than legacy transactions incentivizing the miners to include those transactions first, because they can collect more fees since each block is going to contain more transactions. This has also an impact on the fees for the sender. A legacy transaction is always more expensive since it is heavier and requires paying a higher fee to get confirmed at the same speed as a SegWit transaction.
There are three types of address formats that were introduced with Bitcoin. The first are legacy addresses, they always start with 1:
1Mpf72Q2xwi1okJL1RCaQeVRPKDhEWRtXt
The second are SegWit addresses, they start with 3:
392PTfCzykHSyteg6umCCvbrofRSoJb96i
And the third are native SegWit (bech32) starting with bc:
bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq
Native SegWit is a new format that is even more weight-efficient and is offering a better error detection than the original SegWit format. In effect, using bech32 results in the cheapest fees and fastest on-chain transactions possible on the Bitcoin network.
Is SegWit secure?
Yes, there is no security concern in using SegWit. It is in fact a security update when you consider the removal of transaction malleability of unconfirmed transactions.
Are there any other advantages?
SegWit allowed the implementation of Taproot which allows for smart contracts and even faster validations.
Do I need to accept SegWit transactions?
You can always opt for a legacy wallet that is not using SegWit. It is still possible to send funds between legacy and SegWit addresses. But in return legacy transactions will cost more fees and they are slower.
Wait, does that mean that SegWit is increasing block size after all? Why have a debate then?
The block size was increased to a theoretical level of 4 megabytes. The average block size is now around 2 megabytes. The advantage of SegWit is the fact that it is downwards compatible by respecting the 1 megabyte limit of transaction blocks. It didn’t require a change to the original protocol. On the other hand, increasing the block size above that limit would require a hard fork which is considered a critical event.