There’s more to SegWit than block size.

Bitcoin 2.0 — Part 2 — Segwit

Following this weekly series, I will explain, technically, what is being made to guarantee the future of the network.

In the last article, I explained what a Fork means on the Bitcoin Network and told briefly about SegWit activation, which allowed, among other things, the creation of Side Chains and the rise of transaction capacity on the blocks.
* para ler este artigo em português visite:*

What does SegWit mean?

The term means Segregated Witness and comes from the fact that the protocol basically separates (segregates) the signatures (witness) of a TXIN (input transaction) to the end of the transaction.


The protocol aimed to mitigate a few problems on the Bitcoin Network, among them, the most important ones: the Transaction Malleability and the Transaction Capacity of the blocks.

Transaction Malleability

It was possible for a bad actor to replicate a valid transaction using a full-node while changing its TXID (transaction identifier), causing an invalid double-spend. It’s believed that this attack was used against some exchanges, including Mt Gox.

Basically, the bad actor changed non-sensible data of a transaction somehow maintaining its validity and sending exactly the same values from the same transactions to the same destinations, only changing its TXID. Because of this, someone expecting a specific transaction would never see it included in a block. The con consisted in making the other party redo the transaction without knowing that the first one had already been completed.

SegWit is the third iteration that tried to address transaction malleability and this time it seems like it’s the last one, since instead of using the signature data to generate the transaction hash and consequently its TXID, it uses only the data that really matters like the inputs (where it comes from), the outputs (where it goes to) and, of course, the values to be sent.

The two known bugs that enable this weakness is technically described in my other article here.

Block size

Another problem addressed by the protocol activation was the rise of the block capacity, that was implemented in a very elegant way.

Instead of simply rising the physical limit of the block in MB, they created a new measurement unit called weight. To maintain backward compatibility they have also introduced virtual size (or vsize), where bytes were converted in vbytes, that represents 4 weight units, being that one weight unit represents 1 byte. The blocks created after SegWit activation follow the new changed consensus rules where the limit size of the blocks is 1M vbytes instead of 1MB, or 4M weight (4MB when written on disk or transmitted via network).

A legacy transaction, normally composed of one P2PKH (using compressed public key) input and two P2PKH outputs, occupies 226 vbytes or 904 weight using the new measurement unit.

On the other side, a SegWit transaction, equivalent to the last one, occupies only 222 bytes or 525 weight, a reduction of 61% compared to the legacy transaction.

To perform this math, all the fields that represent witness (markers, flags, and signatures) counts only 1 weight unit per byte while all the other fields are represented in vbytes (4 * weight). In the last example, we have 101 vbytes in common fields and 121 bytes in witness fields (121 + (101 * 4) = 525 weight).

It worth mentioning that SegWit protocol almost doesn’t reduce the size of the blocks written on disk or sent via the network, what changes, are the way we measure the size of the transactions. When we get to 100% SegWit transactions in a block, its max size would be about 2.3 MB, and not 4 MB, thanks to the composition of a SegWit transaction, that has not only fields measured in weight but also fields measured in vbytes.


SegWit implementation enabled full security in a lightweight node since WTXID can be calculated using only the sensible parts of a transaction, cleaning about 60% of disk space when compared to a full node (considering all transactions as being SegWit).

The biggest benefit of SegWit is the capacity to connect not only Side Chains to the Bitcoin Network but to create new layers using Bitcoin, because we can guarantee that the transactions are not being manipulated, besides the fact that we don’t need that much time and space to synchronize the network.

What’s next?

In the next article, I’ll explain one of the biggest promises to assert micropayments using Bitcoin, the Lightning Network, a new layer that connects to Bitcoin using smart contracts that is only secure to use thanks to SegWit implementation.