Segregated Witness was originally deployed in Elements Alpha and introduced to a wider audience by Pieter Wuille in December 2015 at the Scaling Bitcoin conference in Hong Kong. It is specified in BIP 141, which was authored by Eric Lombrozo, Johnson Lau and Pieter Wuille.
By creating a new transaction serialization and a structure called “witness”, scripts and signatures are moved to a new part of transactions.
This has a variety of benefits: non-intentional signature malleability becomes impossible, hard-coded constants can be reevaluated or removed, and the size of witness data can be ignored when calculating the block size, effectively increasing the block size to some extent. It further allows the introduction of new script systems without any limitation from the existing script semantics.
However, there has been a lot of controversy regarding this update, mostly due to a flawed understanding of some technical details. This article attempts to resolve three common misconceptions about Segregated Witness.
1. Segregated Witness gets rid of digital signatures
On September 28, 2017 in an interview with Max Kaiser Roger Ver says:
“If you read the Bitcoin whitepaper itself, it clearly defines Bitcoin as as a chain of digital signatures. The SegWit version of Bitcoin gets rid of those digital signatures.”
Peter Rizun made a similar claim on June 30, 2017 in a presentation called “SegWit Coins are not Bitcoins”, which likely lead to Roger Ver’s statement.
He also claims that:
“A SegWit coin is different, because the signatures are all outside of the chain.”
With Segregated Witness, the transaction serialization has changed in a backwards compatible manner, essentially moving signatures and scripts from the beginning of transactions to the end of transactions. A great visualization of the new transaction format was created by /u/Yoghurt114 and can be found here.
A Merkle root hash is then calculated over all transactions with the new transaction serialization, which also covers witness data, and committed by coinbase transactions.
Because the old serialization is used to determine the size relevant for the old consensus rules, only the first part of a transaction without witness is “counted” in terms of the base block size, effectively increasing the block size, when also considering the witness data. A new limit of 4 MB is introduced for the new serialization, which covers the witness data.
Signature data and scripts are still part of the transaction, and a block with Segregated Witness transactions is still one piece, with transactions serialized in the new format. A block with more than 1 MB of transactions is truly larger than 1 MB, and there are not two blocks or separate pieces. The chain of digital signatures is still intact, and signatures are not lost or discarded, but remain to be part of all blocks. A miner won’t accept a block with Segregated Witness transactions without witness data and signatures.
2. Segregated Witness is an 150 % increase at a 400 % cost
In a paper called “The illusion of scale in segregated witness”, published on July 12, 2017 by nChain, Craig Wright claims:
“Segregated witness increases the amount of data storage and network traffic by 400% to gain a transactional throughput of 150%.”
This statement is false, because it conflates two unrelated values: the block size limit of a block including witness data and an estimated average size of a block, if current transactions were Segregated Witness transactions.
The actual capacity of a block depends on it’s transaction composition. As of today, a total size of 1.7–2.2 MB could be expected in practice. It is also worth to note that hitting the size limit means there are 4 MB of actual transactions.
He further states:
“… segregated witness has 62.5% overhead. That is, it reduces throughput by two thirds.”
As a consequence, his conclusion couldn’t be more wrong.
In fact, native P2WPKH scripts occupy even less space than it’s traditional P2PKH equivalent, which represents a majority of today’s transaction scripts.
3. Miners can steal funds with the “anyone-can-spend vulnerability”
The claim goes roughly like this:
There would be a growing incentive for a 51 % attack as the number of SegWit outputs accumulates. The attack would be to “disable” SegWit, reinterpret SegWit scripts as “anyone-can-spend”, and then steal all SegWit coins.
This was repeated numerous times on Reddit and rehashed by parties like nChain or Bitcoin.com.
A transaction is valid, if nothing in the combined script triggers a failure and the top stack item is non-zero. Scripts are considered as “anyone-can-spend”, if there is no condition attached to be fulfilled for the script execution.
Segregated Witness uses empty scriptSigs (when not using P2SH) and scriptPubKeys that consists of a 1-byte push opcode for 0 to 16, indicating the witness program version, followed by a data push between 2 and 40 bytes for the witness program. The witness program is then interpreted, executed and enforced by Segregated Witness aware software.
Any miner that stops enforcing Segregated Witness rules and starts to create invalid blocks, namely blocks falsely spending coins that require a witness program to be executed, would be partitioned off the network by other miners and users.
But let’s assume the worst case for a moment: 51 % or more of all miners go rogue and start to create invalid blocks by not enforcing Segregated Witness rules. Honest miners would still consider these blocks as invalid and build their own valid chain, but given that they are a minority, at some point they end up as shorter chain.
There would then be two separate chains, one from the rogue miners, and one from the honest miners. They have hard forked and the chains are no longer compatible.
Other participants in the network, in particular full nodes, do not follow the longest chain per se, but the longest chain they consider as valid. Full node users would then also consider the chain from the rogue miners as invalid, and follow the chain of the honest miners, which enforce Segregated Witness rules. Segregated Witness scripts are not vulnerable.
It may be worth to note that nodes running old software, namely software that isn’t Segregated Witness aware, would indeed follow the rogue chain in this scenario. This is expected and inherently the case, given that Segregated Witness is a soft fork.
