SegWit is short for Segregated Witness. It was perhaps the biggest Bitcoin protocol upgrade to date, which wrapped several improvements and fixes into one.
Further Reading: What Is Bitcoin?
As probably its most notable fix, SegWit got rid of transaction malleability. Before SegWit, an oddity about Bitcoin’s cryptographic signatures made it such that transactions could be tweaked to “look” different, even by people who hadn’t themselves created the transaction. While this wouldn’t make the transaction invalid or change what it did — it would still send the same amount of coins from the same addresses to the same addresses — it severely complicated the deployment of layer two protocols like the Lightning Network.
SegWit solved this problem by moving the “witness” data of a transaction, which includes the signature, to a new part of a Bitcoin block. As such, it paved the way for the Lightning Network and other layer two protocols.
Further Reading: What Is the Lightning Network
As an added bonus, SegWit also offered a modest block size limit increase to a theoretical four megabytes, or a more realistic two megabyte limit, depending on the types of transactions included in blocks. (To be exact: The block size limit was replaced with a four million weight unit limit, which introduced a new way to “count” transaction data.) This means that users with SegWit-supporting wallets pay lower transaction fees.
Further Reading: What Is the Bitcoin Block Size Limit?
Plus, through a technical trick called “script versions,” SegWit also made it easier to deploy further upgrades to the Bitcoin protocol. One of these upcoming upgrades could be Schnorr signatures, a new signature algorithm that would further increase the programmability and flexibility of the Bitcoin protocol.
Last but not least, all of this was made possible without requiring a backward-incompatible hard fork protocol upgrade. (Soft fork upgrades require support from only a majority of hash power to avoid a split of the network, while hard forks require network-wide consensus.)
Further Reading: What Are Bitcoin Forks?
A version of SegWit was first developed by Blockstream for the Blockstream Elements sidechain project. After Bitcoin Core contributor Luke-jr figured out how SegWit could be deployed on the main Bitcoin protocol through a backward-compatible soft fork upgrade, it was developed by the Bitcoin Core development team. Specifically, the relevant Bitcoin Improvement Proposal (BIP) was authored by Eric Lombrozo, Johnson Lau and Pieter Wuille, who also did most of the coding. The rest of the team helped throughout the process in various ways, including review and testing.
The pseudonymous Litecoin developer Shaolinfry and Bitmain Warranty engineer James Hilliard are credited with developing alternative activation solutions for the soft fork. (More on this below.)
Within Bitcoin’s technical community, SegWit was not controversial.
Outside of Bitcoin’s technical community, however, some preferred a different scaling solution for Bitcoin or did not believe SegWit itself was sufficient as a scaling solution. This had the effect of turning the SegWit proposal into something of a bargaining chip in a much wider dispute full of controversy. Others tried to discredit SegWit altogether.
The only point of controversy that (arguably) had some validity to it is that it would have been “cleaner,” code-wise, to deploy the upgrade as a hard fork instead of a soft fork, as this would leave less technical doubt in the protocol. Deploying SegWit as a hard fork would have had its own problems, however, which most developers and proponents of SegWit believed would have been much greater.
Some of the other controversies surrounding SegWit — some, for example, claimed it would allow miners to steal funds — are simply hogwash. (Case in point: SegWit has been live for years, and no miners have been able to steal any coins.)
Further Reading: What Is Bitcoin Mining?
SegWit activated in August 2017.
How it activated is a long story. While it was first publicly proposed and included in the Bitcoin Core roadmap in December 2015, and the code was ready less than a year later, it took until the summer of 2017 for the protocol upgrade to go live.
This is in large part because some significant Bitcoin miners refused to activate the protocol upgrade. (As originally designed, SegWit would go live on the network if a supermajority of miners signalled support in the blocks they mined.) The motivations of these miners are still speculated about, but it seems that they either used SegWit as a bargaining chip or they “blocked” the upgrade because it was incompatible with a mining optimization (called “AsicBoost”) that they were secretly using — or both.
Either way, by 2017, a grassroots movement of Bitcoin users rallied around an idea first proposed by pseudonymous Litecoin developer Shaolinfry. Called a User Activated Soft Fork (UASF), these users announced they would activate the upgrade on their own Bitcoin nodes by summer, regardless of what the miners would do. If these users would have gone through with their original plan, it could have split the Bitcoin network into a version with SegWit and a version without.
Mere days before the UASF “deadline,” miners activated SegWit after all. Technically speaking, they did this through yet another activation mechanism, proposed by Bitmain Warranty engineer James Hilliard.
For a full account of this chapter in Bitcoin’s history, also see The Long Road to Segwit: How Bitcoin’s Biggest Protocol Upgrade Became Reality.
You use SegWit by using a wallet that has integrated SegWit. This wallet should generate SegWit addresses for you, and when you make a payment from such an address the fee you will need to pay will be lower than if you hadn’t used SegWit.
There are two types of SegWit addresses. One type (“P2SH”) starts with a ”3” — though not all addresses that start with a 3 are Segwit addresses. The other (“bech32”) starts with “bc1,” and is always a SegWit address. P2SH SegWit addresses are actually a bit of a workaround; while SegWit transactions from such addresses are cheaper than non-SegWit transactions, transactions from bech32 addresses are the cheapest.
Addresses that start with a “1” are never SegWit addresses.
Some wallets that have integrated SegWit include Bitcoin Core, Electrum, Green, Trezor, Ledger and a number of others.
Well over two years after SegWit activated, less than half of all transactions on the Bitcoin network utilize SegWit. From an individual perspective, there are probably two reasons not to use SegWit.
The first reason is that implementing SegWit requires an upgrade, and some people are simply slow to do that. For large companies, it may require significant time and effort as whole systems may need to migrate. Similarly, some wallets and other applications just haven’t integrated SegWit yet, presumably because they have other priorities.
The second reason would be “political”: Some people suspect that certain companies aren’t upgrading to SegWit as a sort of protest. They would have preferred different scaling solutions or more scaling solutions. They may even be trying to drive up transaction fees on Bitcoin in order to incentivize users to migrate to altcoins.
It’s worth noting that even if everyone doesn’t upgrade to SegWit, those who do upgrade enjoy the benefits regardless. While the overall fee level might be slightly lower for SegWit users if everyone else were to use SegWit as well, the added benefit of complete migration is small. Plus, if fewer people use SegWit, Bitcoin blocks are smaller which has benefits as well.
