written by @emylacapra
SegWit, or Segregated Witness, is an upgrade to the Bitcoin protocol, implemented in August 2017 by Bitcoin Core developer Pieter Wuille.
Pieter Wuille had been working on SegWit since 2015, when he presented it at conferences for developers in Hong Kong and San Francisco. SegWit helped resolve a number of problems, but in this article we explore the two improvements that relate to users experience; scalability, with an increase in block size, and security, by eliminating the risk of transaction malleability.
Let’s see how!
Initially, Satoshi Nakamoto had not given a specific size limit to bitcoin blocks that in 2010 had a capability of around 500-750k. In July of the same year, he capped the block to 1MB secretly and with not much explanation, although early developers believed that he wanted to avoid spam transactions being added to the network by unscrupulous actors in order to perform a DoS attack (denial of service attack).
As the network grew and became more popular, the number of transactions began to add up. The limit of 1MB or approximately 2,500 txs per block/4.2 transactions per second became a low-hanging ceiling. In comparison to a payment network like Visa’s 1,700 tx/sec, Bitcoin did indeed have a reduced throughput.
Core developers pointed out early that in order to free up some block space and validate more transactions faster, some transaction data must be utilized in a more efficent manner. Transaction data includes the addresses of inputs (sender) and outputs (receiver), plus scripts like digital signatures (witness) which allow to verify that the sender is eligible to send the coins.
Since digital signatures are only needed at validation time – and only for fully validating nodes – they do not need to be maintained in the same data structure as inputs and outputs for the system to remain unchanged. It soon became clear which data could shuffled around externally from the previous 1MB limit, and signature segregation constituted the backbone of Pieter Wuille’s SegWit.
Segregated Witness is, therefore, a process of segregating (removing) the witness (the digital signature) from the main data structure and allocating it to a separate area of the same block.
Signatures account for approximately 60% of the blockchain size. SegWit’s implementation allowed clients to no longer count this data as part of the 1MB limit, effectively increasing transaction throughput while also creating an environment with cheaper transaction fees as a result.
Why Choose Segwit-Enabled Wallets?
SegWit blocks can feasibly reach up to a 4MB limit, where the1MB consensus rule is still observed by all data except the signatures, and ~3MB are available in the extended block which accommodates the signatures.
As signatures are still kept within the same block, SegWit is considered as a soft fork and not a hard fork. In layman’s terms: it is backward compatible with older implementations, allowing non-upgraded software to ignore the change while continuing to operate without any disruption.
Does SegWit Resolve The Issue Of Scalability?
The answer is that it does, for now.
Bitcoin expert Andreas Antonopoulos is quoted as saying:
“Scale is not a goal to achieve; it is a definition of what you can do with the network today.” (The Internet of Money)
As we’ve experienced with the Internet, scalability does not get resolved for good, but rather happens at different stages and according to the requirements of the time. Having 32MB blocks right now, for example, would mean having mostly empty big blocks we don’t need yet. It could resolve scalability of the future to the detriment of decentralisation by making DoS easier and shifting a lot of power to a few miners and centralised nodes.
That’s why SegWit is only the first step. The likely next phase is the implementation of Schnorr Signatures and Aggregation Signatures built upon SegWit, which introduce 25% to 30% improvement in capacity by optimising signatures.
By removing the signatures from the transaction hash, SegWit also solves the malleability problem. That occurs when a receiver could intercept and modify the sender’s transaction ID from unconfirmed transactions sitting in the mempool, in order to claim they never received the original transaction and get more coins from the sender.
When the digital signature is detached from the input, a fraudulent party cannot change the transaction ID without also nullifying the digital signature. In simple terms, SegWit fixes transaction malleability by making it impossible for a third party to malleate the transaction and produce a different transaction ID with the same spendable amount.
This process also enables the implementation of the Lightning Network where parties exchange signed bitcoin transactions which are not broadcast to the network (because they are sitting on a second layer) but depend on base transactions that are transmitted to the network (base layer).
Here’s the reason why that matters: for two parties to pre-agree a transaction which spends outputs that have not been confirmed yet, the transaction ID of the yet-to-be-committed transaction must be secured first. If the transaction ID can change between the time it’s signed and the time it gets validated in the main chain, then any transaction spending out of it can be invalidated. SegWit is a necessary prerequisite for the Lightning Network to function.
With SegWit, different types of addresses had to be created.
Legacy addresses start with “1”, while SegWit can either start with “3” (wrapped segwit) or “bc1” (bech32). Here’s a breakdown of interoperability:
- 1 addresses can receive from any other address, but can only send to other legacy or 3 addresses.
- 3 addresses can send and receive freely amongst any other address type.
- Bc1 addresses can send to any other address, but can only receive from bc1 or 3 addresses.
Bitcoin doesn’t automatically upgrade to SegWit but it relies on the nodes of individuals, wallets, exchanges and companies to upgrade themselves and propagate changes to the network accordingly in order to use it.
Over time, SegWit adoption has increased considerably. Yet, it’s still only used in roughly 50% of transactions. Reasons for this can vary, but for a start, it is very costly to implement for mining hardware providers who need to upgrade their components appropriately.
In early 2017, one event shook the Bitcoin community when Bitcoin core developer Greg Maxwell revealed that one mining hardware provider was secretly exploiting a bitcoin’s weakness in its algorithm that allowed them to mine at a 20% faster rate than any other competitor. SegWit would make the so-called AsicBoost technology, used to exploit the defect, obsolete.
By not adopting the upgrade under the guise of altruism, the mining hardware company was considered by many to be dishonestly cheating the market while penalising users of the network. The company in question was China-based Bitmain, although co-founder Jihan Wu has always denied they were using that technology to mine bitcoin.
SegWit’s implementation also sparked significant controversy within the bitcoin community for several other reasons.
Some believed that offloading data from the blockchain was a failure, and that anything external to Bitcoin’s main chain was not a legitimate Bitcoin transaction. For this reason, instead of adopting SegWit, a number of individuals hard forked into Bitcoin Cash in 2017. They wanted to achieve scalability by increasing the block size and keeping all data on-chain.
The event split the bitcoin community between those who believe the scaling issue should be resolved by increasing the permissible amount of transactions in bigger blocks, and those who believed alternative fixes like SegWit and the secondary layers solution it enables, like the Lightning network, were more efficient and preserved decentralisation.
In 2017, a new upgrade was proposed as a hard fork called SegWit2x. It was supposed to increase block size from 1MB to 2MB with the main purpose of mitigating fee increases. In contrast to Bitcoin Cash’s hardfork, the SegWit2x implementation hoped to implement a block size increase to 2MB months after the successful addition of Segwit. Ironically, much of the support for large blocks had already moved over to Bitcoin Cash, perhaps contributing to the proposal’s monumental failure.
Segwit2X seemed to pick up steam over the second half of 2017, garnering the support of nearly 80% of network miners, as well as 50 of the top Bitcoin companies at the time. A successful migration to the new chain would have also meant the installation of a new (smaller) set of developers, leaving behind the Core contributors that had done an excellent job maintaining the protocol to date. However, a vocal group of users running their own nodes stood in defiance, unwilling to be swayed on protocol changes based on the whims of large corporations.
Pair the above with the launch of futures markets valuing a hypothetical Segwit2X coin at only 25% of Bitcoin’s current value at the time, the promoters of SegWit2x were all but forced to give up the initiative. The suspension of the plan was announced in a communication by Mike Belshe, CEO of Digital Asset Trust company BItGo. It cannot be stressed enough how unprecedented it was to see a ragtag group of computer nerds peacefully run some software on their computers, vote with their capital, and take down what was thought to be an easy power grab by the CEOs and key players in an entire industry.
Jump to today, and it seems clear as to which direction was the most robust and secure option tackle Bitcoin’s scalability. A multi-layered solution with infinite built-upon structures that follows the Internet’s infrastructure choices, appears to have provided a decentralisation safeguard, which, it’s worth remembering, remains the principal goal of Bitcoin.
If you have any feedback on this or any other topic, please feel free to reach out to us at any time at firstname.lastname@example.org or @BTSEcom on Twitter. We always love to hear from our amazing BTSE community.