As of block 481,824, which was mined by BTCChina Pool at 1:57 A.M. on August 24, 2017 (UTC±00:00), Segregated Witness (segwit) activated on the Bitcoin network.
The long-awaited and much-anticipated activation of the segwit soft fork, which came after two years of increasingly hostile debates over its viability and efficacy, ushers in a slew of new features that aims to enable a significant boost to Bitcoin’s usability, utility, and transaction-processing capacity.
This article takes a deep dive into what segwit is and why it was created, its benefits for and potential impact on Bitcoin, and how and when you can start making segwit transactions.
What Is Segwit and Why It Was Created
Segwit, as defined in BIP141, is a soft fork designed primarily to fix a critical bug in the Bitcoin network called transaction malleability. Introduced on December 21, 2015 by Bitcoin Core contributors Eric Lombrozo, Johnson Lau, and Pieter Wuille, BIP141 aimed to fix this bug by rearranging the way transaction data is stored in Bitcoin blocks.
Each and every Bitcoin transaction is identified by a corresponding unique 64-digit hexadecimal hash. This hash is called a transaction identifier (txid), and it looks something like this: 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b. (Fun fact: this transaction is the first-ever Bitcoin transaction, being the coinbase transaction in the first-ever Bitcoin block, also known as the genesis block). A transaction’s txid is based both on the coins being spent (the transaction’s input) and on whom will be able to spend the results of the transaction (the transaction’s output).
Prior to segwit, the calculation of a transaction’s txid included the transaction’s signatures. A signature in this context can be thought of as a sort of cryptographic wax seal that proved that the owner of the coins being spent really did authorize the coins to be spent.
Unfortunately, this way of calculating the txid allows anyone to make small modifications to the transaction that does not change its meaning, but changes its txid. For example, if Alice sends 0.1 BTC to Bob in a transaction with txid ab12…yz89, a third party — such as a node on the Bitcoin network that relays the transaction or the miner who includes the transaction in a Bitcoin block — can modify the transaction in such a way that although the transaction still pays 0.1 BTC from Alice to Bob, it ends up being confirmed in the Bitcoin block under the completely different txid 07qw…3rha instead. This phenomenon is called third-party malleability.
There is another form of transaction malleability enabled by this way of calculating the txid. Here, a transaction’s txid — but not the transaction’s meaning — can completely change if one or more signers of the transaction revise their signatures. In other words, the transaction remains valid and pays the same amounts of bitcoins to the same addresses, but its txid becomes completely different because the calculation of the txid was affected by the revised signatures. This type of transaction malleability is called scriptSig malleability.
Segwit’s Malleability Fixes
Segwit prevents both third-party and scriptSig malleability by moving the malleable parts of the transaction — i.e., the transaction’s scripts and signatures — into a new structure called the transaction witness, and then segregating this witness from the base component of a Bitcoin block (hence the name Segregated Witness).
With the transaction’s scripts and signatures now tucked away in its own separate structure, any changes to the transaction’s scripts and/or signatures no longer has an effect on the calculation of the transaction’s txid. This is because the transaction’s txid can now no longer be modified by changes to the transaction’s scripts and/or signatures. There can therefore be no more third-party and scriptSig malleability.
Segwit’s Benefits and Potential Impact on Bitcoin
Unconfirmed Transactions, Smart Contracts, and the Lightning Network
Transaction malleability, while not a critical problem in and of itself, has nevertheless been a significant roadblock in developers’ ambitions to implement more complex features in Bitcoin — e.g., smart contracts and second-layer protocols like the Lightning Network. This is because such features (especially second-layer protocols) rely heavily on the use of unconfirmed transactions, and transaction malleability makes unconfirmed transactions especially risky for all parties involved.
For example, if Alice pays Bob 0.1 BTC in transaction 1, Bob pays Charlie 0.1 BTC in transaction 2 (before transaction 1 has been confirmed in a Bitcoin block), and then transaction 1’s txid becomes malleated, transaction 2 becomes invalid. This is because the txid which transaction 2 relied on no longer exists, and so the Bitcoin network no longer recognizes transaction 2 as having any valid inputs. If Bob is trustworthy, he will simply reissue the 0.1 BTC to Charlie. But if Bob wants to, he can keep the 0.1 BTC to himself.
With segwit fixing transaction malleability, anyone spending unconfirmed transactions can be assured that such scenarios will not happen. More importantly, large-scale second-layer protocols that rely on unconfirmed transactions, such as the Lightning Network, and smart contracts become much less complicated to design and much more efficient in their implementation, because developers will no longer have to account for malleated scripts and signatures. This bodes well for Bitcoin’s future capabilities, as the Lightning Network not only paves the way for the Bitcoin network to process much greater volumes of transactions than what it can currently handle, but the Lightning Network also enables cross-chain atomic swaps, which enables two parties on two different blockchains — e.g., Bitcoin and Litecoin — to trade with each other directly, without the need for a third-party exchange platform.
Increased On-Chain Capacity
Although segwit has often been presented and described as a scaling solution to Bitcoin’s block size dilemma, it is important to note that segwit was never designed to be an out-and-out scaling solution in the first place. Rather, segwit, from the beginning of its development, has always been primarily targeted at fixing Bitcoin’s transaction malleability problem, which in turn was the problem that kept Bitcoin from adopting more advanced scaling solutions. Segwit’s incidental boost to Bitcoin’s on-chain capacity should therefore be thought of as more of a pleasant side-effect of segwit’s main goal, rather than as segwit’s main goal itself.
Because segwit moves transaction signatures into a separate structure that is unknown to non-segwit nodes, and because this witness data is required only for validating transactions and not for actually determining their meaning, the witness (and therefore its size) can be ignored when calculating the block size. This, in turn, effectively increases the block size in a manner that is backward-compatible.
In other words, non-segwit nodes will continue to enforce Bitcoin’s current 1 MB block size limit on all blocks that they see and download. These blocks will be downloaded without the witness structure, since non-segwit nodes are unable to recognize the witness structure. Segwit nodes, on the other hand, are able to recognize the full block together with its witness data. Segwit nodes are therefore able to take advantage of this by defining a new limit, one that allows for larger block sizes and yet remains compatible with older, non-segwit nodes. This new limit is called the block weight, and is capped at 4 MB.
The block weight takes into account two parameters: the block’s base size and the block’s total size. The block’s base size is what non-segwit nodes see — i.e., up to 1 MB of transactions without any witness-related data. The block’s total size is what segwit nodes see — i.e., up to 4 MB of transactions including witness-related data, of which up to 1 MB of the block must be the base size (to remain compatible with non-segwit nodes).
Segwit therefore enables larger effective block sizes — without sacrificing backward-compatibility — by enabling more transactions to fit into a block’s base structure. Non-segwit nodes see more transactions per block (albeit without witness-related data), and segwit nodes see more transactions overall (with lightweight segwit clients having the option of disregarding witness-related data to save on bandwidth and storage space).
Lower Transaction Fees
This is probably the benefit that users look forward to the most.
Because segwit transactions take up less space per block, and also because of segwit’s impact on reducing the growth of Bitcoin’s Unspent Transaction Output (UTXO) database, segwit transactions are expected to cost up to 75% less in transaction fees compared to non-segwit transactions. And because more segwit transactions relative to non-segwit transactions per block means more available space per block for transactions, average transaction fees across the board can be expected to reduce in tandem with greater segwit adoption.
How and When You Can Start Making Segwit Transactions
Although segwit itself has now activated on the Bitcoin network, its benefits do not automatically apply across the board immediately. A transaction has to be made from a segwit-enabled wallet, with bitcoins in segwit addresses, for segwit’s benefits to apply. And segwit adoption has to reach a statistically-significant threshold before it would have a noticeable impact on Bitcoin’s transaction fees and overall network capacity.
Thankfully, although overall adoption of segwit has been off to a slow start, there are a handful of wallet providers who have begun to enable segwit support in their product offerings, with more on the way. Hardware wallet providers, such as Trezor and Ledger, have been among the first to roll out segwit support.
If you’re a Trezor Wallet user and would like to start using segwit, simply follow Trezor’s guide to enabling segwit here.
If you’re a Ledger Wallet user and would like to start using segwit, simply follow Ledger’s guide to enabling segwit here.
Also, on September 6, 2017, GreenAddress became the first software wallet to offer full segwit functionality. If you’re a GreenAddress user and would like to check if your GreenAddress wallet is using segwit, you may find instructions for doing so here.
Full-node wallets, like the one included with Bitcoin Core, currently do not make segwit transactions by default. While it is possible to generate segwit addresses by using the addwitnessaddress remote procedure call (RPC), the Bitcoin Core wallet currently does not have a mechanism to generate segwit change addresses. This means that whenever you send bitcoins from a manually-generated segwit address, its change is going to a non-segwit address. Full segwit functionality in Bitcoin Core is scheduled to be implemented in version 0.15.1, although there is currently no expected timeline for when Bitcoin Core 0.15.1 would be released.
P2SH Segwit Addresses
All current and future segwit-enabled wallets are expected to generate receiving addresses that start with the number 3 when generating segwit addresses. Addresses that start with the number 3 are known as pay-to-script-hash (P2SH) addresses.
All current bitcoin wallets are able to pay P2SH addresses. This means that if you’re using a segwit address to receive payment, you would be able to receive payment from any current bitcoin wallet, regardless of whether or not the sender’s wallet has been upgraded to support segwit.
Similarly, when sending bitcoins from your segwit addresses, you would still be able to send the bitcoins to legacy bitcoin addresses — i.e., addresses that start with the number 1, also known as pay-to-public-key-hash (P2PKH) addresses — as well as to other P2SH addresses.
When sending bitcoins from your segwit wallet, you may notice one of the following:
- When sending only bitcoins from your non-segwit addresses to another address (segwit or non-segwit), you would not notice any difference in the current transaction compared to a pre-segwit transaction.
- When sending bitcoins from your segwit addresses to a non-segwit wallet, the recipient of your sent bitcoins may not see the transaction until after it is included in a Bitcoin block. This is because the recipient’s non-segwit wallet is unable to fully understand the segwit transaction, and so the wallet disregards it until the wallet sees the confirmed transaction in a Bitcoin block.
- When sending bitcoins from your segwit addresses to other segwit addresses, you may notice that the transaction fee may be lower than the fee you would have paid if you made a non-segwit transaction.
Native Segwit Addresses
Sometime in the near future, native segwit addresses that incorporate more advanced features are expected to be introduced. These native segwit addresses — available in two flavors: native pay-to-witness-public-key-hash (P2WPKH) addresses and native pay-to-witness-script-hash (P2WSH) addresses — enable even smaller transaction sizes, and therefore less fees per transaction, compared to current P2SH segwit addresses, as the native segwit addresses are more efficient in their use of available block space.
There is currently no expected timeline for when native segwit addresses would be ready for mainstream deployment.
It has been a long road for segwit, but now that it’s finally active on the Bitcoin network, the stage is set for significant boosts to Bitcoin’s usability, utility, and transaction-processing capacity — with the Lightning Network, more complex smart contracts, and lower transaction fees now all within reach of Bitcoin’s capabilities.
The final frontier for segwit: mainstream adoption.