It is often said that Bitcoin is resistant to change. To a degree, that’s correct — Bitcoin developers are incredibly conservative when it comes to integrating protocol improvements — but it misses the bigger picture: Bitcoin embraces change, but only for the better.
In entering the role of a currency, something no technology has previously managed to do, Bitcoin must be bulletproof. There is no room for network downtime, buggy blocks, overflows or rounding errors. Bitcoin must be stable: any improvement or alteration to its code could have devastating economic effects if it is not treated with the utmost caution and diligence.
Recommended reading: Why is Bitcoin development so conservative?
Simply because a proposed improvement could have beneficial effects for some network participants does not mean it qualifies. Bitcoin developers will not risk the integrity of the network for anything but unanimous benefit. This means making it more accessible and useful for everyone, not chasing features that only a small subset will use.
Why SegWit was important
Four years ago today on August 24th 2017 at block 481824, the SegWit upgrade was activated. Described in BIP141 through BIP144, SegWit addressed a malleability issue and at the same time tackled scalability worries related to block size limits.
At the time, even after being included in the Bitcoin Core codebase, whether SegWit should be adopted by the community became a heated debate which highlighted the power dynamic between node operators and miners.
Many miners did not support SegWit, for a variety of reasons, and sought to block the fork. But the perceived benefits to users ultimately resulted in a push for a User-Activated Soft Fork (UASF), a forced network upgrade which would be pushed through by nodes by rejecting blocks from uncooperative miners. This was a historic moment for Bitcoin, demonstrating that the network is decentralized and that miners serve the users, rather than the other way around.
How SegWit works
SegWit’s primary objective was not to save block space, but to fix transaction malleability. Prior to SegWit, an unconfirmed transaction’s ID (txid) could change after being confirmed, due to included scripts or a change of the signature itself. By placing this ScriptSig data in a new part of the transaction called the witness, one that is not used to hash the txid, it became possible to rely on txids of unconfirmed transactions. This is essential to the Lightning Network.
Recommended reading: Bitcoin account types
While the key improvement was making transaction ID’s dependable, moving the script and signature data to the Witness prompted developers to come up with a new process for evaluating transaction fees using block weight instead of block size for calculations. Prior to Segwit, the block size was 1,000,000 bytes. After SegWit, the limit was changed to 4,000,000 weight units which translates to an average of 1.5–2.0MB blocks depending on the transactions contained within, with an upper size threshold of 4.0MB. By treating witness data as 1 weight unit and regular data as 4 weight units, more transactions could be fit into a block which had a knock-on effect of lowering transaction fees.
What we learned from SegWit
As a learning experience, SegWit has taught us a lot about Bitcoin, both in practical and philosophical terms. The SegWit upgrade saw the broader community stand up to self-interested miners, coercing them to accept the upgrade by refusing to accept non-Segwit blocks. This leveraged Bitcoin’s game-theory economics by undermining miners’ incentives — if their blocks are rejected, they can no longer accrue funds from fees or block subsidies.
Nodes hold the power
The user-activated soft fork, as it was called, demonstrated the extent of nodes’ power within the system. Not the miners, who made significant capital investments into expensive ASIC hardware to control large shares of the network’s hashpower, but otherwise insignificant users who simply maintain a copy of the Bitcoin ledger for verification. It was the biggest stress test of Bitcoin’s user-focused decentralized principles, and it had the desired effect of forcing miners to accept the fork.
The SegWit upgrade had some side effects, such as the blocksize wars which gave a platform to many miners for whom SegWit was unacceptable and an increased block size was preferable. One reason for this is presumed to be that some miners used an exploit known as AsicBoost to increased mining efficiency, which would not be compatible with SegWit.
This conflict served to identify not only the proponents of Bitcoin, but also to weed out those who would only let the network be changed if it ensured their benefit. The fallout from this was twofold: some miners split off to support a forked chain, while the Bitcoin network saw a painfully slow uptake of SegWit and it took over a year to reach 50% support.
Forks needn’t be contentious
For a while it was uncertain what the outcome of Segwit would be. Setting nodes against miners caused an undesirable rift in the community and without pressure from the users the upgrade may have gone differently, or not have happened at all. Nonetheless, it was a learning experience that carried over to the next upgrade, this year’s Taproot soft fork, which was recently locked in.
Recommended reading: What is taproot?
The voting process for Taproot was more formalized than SegWit, with a long period during which miners were encouraged to upgrade their clients and signal for Taproot long before the expected activation. Each block mined by a supporting mining pool counted as a vote for activation, with the vote passing once over 90% of blocks produced during the voting period had signaled their support.
This method put miners’ consensus ahead of users, avoiding the drama of a split opinion between regular nodes and miners. If support for Taproot had not been agreed upon by miners before the end of the signalling deadline, we would no doubt have seen another call for a User Activated Soft Fork.
In future, we can expect to see similar processes applied to network upgrades, but whether it will follow the same process as Taproot is yet to be seen. There is a risk of malicious actors gaming the system if this process is standardized, but by letting miners vote ahead of attempting a UASF that should be avoided.
Struck by Lightning
While the slow adoption of SegWit was a disappointing outcome, the advantages it brought about are now becoming clear. The Lightning Network, a second-layer network built on top of Bitcoin, has been making ever bigger headlines over the past year. Offering instant, practically feeless payments settled on Bitcoin, Lightning makes Bitcoin much more accessible and practical for regular people. If used right, it can even offer a boost to privacy.
Without SegWit, reliable instant payments would not have been possible but in fixing the malleability problem mentioned above has opened the doors to a host of new use cases. By having an instant payment and data routing layer on top of Bitcoin, further layers dealing with computation — like smart contracts, dApps and special-purpose networks — can also be added.
SegWit unlocked new potential for Bitcoin. As Lightning grows, so will the number of new functions it can serve. While experimental altcoins have explored many novel applications over the years, it is likely that some of the more practical use cases will be migrated to a computational layer built on top of Lightning, secured by Bitcoin. With Taproot activation now locked in and approaching in November, we can expect more efficiency and yet more innovation coming to Bitcoin in the coming years. Hodl on to your hats!
