{"id":23309,"date":"2017-08-23T04:00:00","date_gmt":"2017-08-23T04:00:00","guid":{"rendered":"http:\/\/ci027daccc600027c4"},"modified":"2017-08-23T04:00:00","modified_gmt":"2017-08-23T04:00:00","slug":"the-long-road-to-segwit-how-bitcoins-biggest-protocol-upgrade-became-reality","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/technical\/the-long-road-to-segwit-how-bitcoins-biggest-protocol-upgrade-became-reality","title":{"rendered":"The Long Road To SegWit: How Bitcoin\u2019s Biggest Protocol Upgrade Became Reality"},"content":{"rendered":"
<\/div>

Segregated Witness (SegWit) has activated<\/a> on Bitcoin. As of today, all SegWit-ready nodes on the Bitcoin network are enforcing the new rules, marking Bitcoin\u2019s biggest protocol upgrade to date.<\/p>\n

But activation did not come easy, and it did not come fast.<\/p>\n

This is a look back at the long road to SegWit.<\/p>\n

The Problem<\/h2>\n

Bitcoin transactions consist of two main parts. One part is \u201cbase transaction data.\u201d That covers which bitcoins are being moved and where they are being moved to, as well as some other data. The second part is called the \u201cwitness.\u201d This contains a bit of code with cryptographic signature data, which proves that the owner of a bitcoin really did want to spend the bitcoin.<\/p>\n

It\u2019s this signature data that brings a slight complication with it. In what is referred to as the \u201cmalleability bug<\/a>,\u201d Bitcoin signatures can be slightly altered by anyone, even after these signatures are created and without invalidating the signatures. This in turn means that the appearance of the whole transaction, and more specifically the transaction identifier, can be altered by those relaying transactions over the Bitcoin network or by miners that include transactions in blocks.<\/p>\n

This doesn\u2019t need to be a big problem in itself. Transactions are still valid and will move the bitcoins from the same place to the same place, under all the same conditions. However, it does complicate creating newer transactions depending on unconfirmed transactions: New transactions need to know the transaction identifier they rely on. This, in turn, makes it significantly harder to build certain second-layer protocols on top of Bitcoin, like bi-directional payment channels.<\/p>\n

The Idea<\/h2>\n

The general idea to solve the malleability bug by \u201cseparating\u201d signature data from other transaction data stems back several years.<\/p>\n

As far back as 2012, the likes of Bitcoin Core <\/a>contributors Russell O\u2019Connor, Matt Corallo, Luke Dashjr and Gregory Maxwell, as well as Bitcointalk moderator \u201cTheymos,\u201d discussed<\/a> the issue on IRC Bitcoin development channels \u2014 but at that time they didn\u2019t see a tenable way of pulling it off on the Bitcoin network.<\/p>\n

A year later, in August 2013, the issue resurfaced<\/a>, as Bitcoin Core contributors Peter Todd and Gregory Maxwell were having similar discussions on IRC. But now, the two were making progress with their ideas to counter malleability. \u201cI\u2019m talking about making the [entirety] of the scriptsig largely [separate],\u201d Maxwell wrote. \u201cI\u2019d even suggest using as [transaction ID] the transaction without the scriptsigs.\u201d<\/p>\n

Another month later<\/a>, Maxwell and, this time, well-known cryptographer Dr. Adam Back were discussing the malleability issue on IRC once again. Now, Back suggested computing the transaction ID by omitting the signature. Though, Maxwell commented, \u201cgetting the sig out of the txid could help but that would be a very deep hardforking change \u2026 and it\u2019s actually tricky to make secure.\u201d<\/p>\n

The Sidechain<\/h2>\n

In August 2014, blockchain technology company Blockstream<\/a> was founded by the same Adam Back and Gregory Maxwell, as well as entrepreneur and investor Austin Hill and several Bitcoin Core developers, including Dr. Pieter Wuille. The company was set to focus on sidechains: alternative blockchains that can effectively be pegged to Bitcoin.<\/p>\n

By early 2015, Blockstream engineers decided to implement a new feature in the company\u2019s prototype sidechain Elements<\/a>, which was publicly announced<\/a> in June of that year. This feature would conclusively solve the malleability issue on the sidechain \u2014 by separating base transaction data from witness data into different data structures.<\/p>\n

The name of this new feature was, of course, Segregated Witness<\/a>.<\/p>\n

The Block Size Dispute<\/h2>\n

It had been looming for some time, technically since October 2010<\/a>, more concretely since February 2013<\/a> and finally publicly<\/a>, bursting onto the scene<\/a> by the spring of 2015: the block size limit dispute.<\/p>\n

Former Bitcoin Core lead developer Gavin Andresen and Bitcoinj<\/a> lead developer Mike Hearn, in particular, believed that Bitcoin\u2019s 1 megabyte block size limit should be increased with a hard fork, an incompatible protocol change that would require almost the entire Bitcoin ecosystem to upgrade. No easy task \u2014 even more so because there was no community-wide consensus for this change.<\/p>\n

Regardless, by the summer of 2015<\/a>, Andresen and Hearn announced that they would move forward with their plans, using the alternative Bitcoin XT<\/a> software client. The controversial nature of the effort put the Bitcoin development community and industry in somewhat of a state of emergency.<\/p>\n

In an attempt to resolve the divide and potentially help figure out a resolution to the block size dispute, two conferences (or workshops) were quickly organized in the latter half of 2015: Scaling Bitcoin Montreal<\/a> and Scaling Bitcoin Hong Kong<\/a>.<\/p>\n

One of the most promising scaling proposals presented<\/a> in Montreal was the<\/a> lightning<\/a> network<\/a>, a sophisticated second-layer scaling solution that was detailed in a white paper<\/a> published by Joseph Poon and Thaddeus Dryja only months earlier. The only problem: this solution would require a malleability fix.<\/p>\n