Segregated Witness might be the most significant improvement to the Bitcoin protocol to date. The innovation is set to fix transaction malleability, offers an effective block size increase, enables development flexibility and more. After months of coding, Segregated Witness is getting close to rollout, as a pull request was submitted to Bitcoin Core earlier this week.

How close to roll-out exactly? As with any change to the Bitcoin protocol, that is hard to predict.

A Segregated Witness timeline …

Step One: The Idea

Each improvement to the Bitcoin protocol starts with an idea.

The Segregated Witness idea goes back a long time; the general concept to separate transaction and signature data probably originated in 2014, or perhaps even sooner. But it was about a year ago, early 2015, that Blockstream’s Bitcoin and sidechain development team decided to implement the concept in their prototype sidechain: Elements. Elements, which includes Segregated Witness, was mostly designed by Bitcoin Core developer and Blockstream co-founder Gregory Maxwell and released in June 2015.

At that point it was still thought impossible to implement Segregated Witness on the Bitcoin blockchain, however, unless it was through a hard fork. Separating transaction and signature data would incompatibly change the structure blocks, which could cause a split in the Bitcoin network between upgraded nodes and non-upgraded nodes.

In the autumn of 2015, it was Bitcoin Core developer Luke Dashjr who figured out how to implement Segregated Witness in the main Bitcoin protocol, after all. Using a clever hack, Segregated Witness transactions can be marked as “anyone-can-spend” transactions for non-upgraded nodes, while upgraded nodes are redirected to an “add-on block” with signature data. This solves the incompatibility issue, meaning Segregated Witness can be rolled out as a soft fork.

This option was first discussed among Bitcoin Core developers through typical communication channels: by private email, on IRC, a little later on the Bitcoin development mailing list and elsewhere. Everyone involved in the conversation agreed it was a good idea.

A couple of weeks later, in December 2015, Segregated Witness was publicly presented by Bitcoin Core developer Pieter Wuille at the Scaling Bitcoin workshop Hong Kong.

Estimated time: 1 year

Step Two: The Code

An idea in itself doesn’t change anything. Someone needs to write the code to realize the idea.

Wuille began coding Segregated Witness in November 2015 – a couple of weeks before he presented the idea in Hong Kong. Excited by the potential, Bitcoin Core developer and Ciphrex CEO Eric Lombrozo, Bitcoin Core developer Johnson Lau and some other developers started contributing as well.

Five months later, Segregated Witness for Bitcoin Core counts 4,743 lines of code (including test code), and proposes to remove or modify 554 of existing lines of Bitcoin Core code. Wuille and the other contributors consider it done.

Total time: +-5 months

Step Three: The Review

As the code is considered completed, Wuille submitted a pull request this week. A pull request is basically an “official” proposal on development platform GitHub to merge a batch of code – Segregated Witness – into Bitcoin Core’s master branch: the continually evolving heart of the project on which new Bitcoin Core releases are based.

This marks the start of the technical review process. Other developers are invited to review and test the code, and offer their opinion. This can be done in the form of a comment, or through a type of vote: “ACKs” (in favor) and “NACKs” (against). There are also several subdivisions of ACKs and NACKs, for instance to indicate that the code has been tested by that developer – or not.

The review process will take as long as the Bitcoin Core repository maintainer – currently Wladimir van der Laan – considers necessary. If he believes rough consensus for a merge is (and will remain) absent, he can close the pull request. The proposal is rejected, and the submitter can opt to re-write the code.

More likely, in the case of Segregated Witness, the review process will provide feedback to Wuille and the other developers, which could lead to slight changes to the code.

And if Van der Laan at some point believes there is rough consensus for a merge, he will merge the pull request. Segregated Witness then becomes part of Bitcoin Core’s master branch.

In the case of Segregated Witness, it’s hard to say how long it will take for the pull request to be merged. However, since it is a big change, the process will take several weeks to a month, or perhaps a bit longer.

Estimated time: 2 to 6 weeks

Step Four: The Release

Once the pull request is merged into Bitcoin Core’s master branch, it will need to be offered to the public through a new Bitcoin Core release.

Bitcoin Core offers two types of releases: major releases (which typically change the second number in the release version, like 0.10.0, 0.11.0, 0.12.0, etc.) and minor releases (changes the last number, like 0.12.1, 0.12.2, etc.). Major releases are scheduled about twice per year, but usually don’t include any proposed soft forks. This is so anyone can adopt the perks of a new major release, even if they don’t want to upgrade to the proposed soft fork. 

Minor releases are offered whenever code for a proposed soft fork (or bug fix) is merged, and Van der Laan believes there is rough consensus for a release. (This is normally discussed during weekly IRC meetings.)

All releases – major and minor – are first tagged as “release candidate.” A release candidate is a proposed release, which is first publicly offered for testing. If any bugs or other problems are found in the release candidate, a new release candidate is created and publicly offered for testing as well. 

Additionally, all releases - major and minor, as well as release candidates - go though a technical building and signing ritual (“gitian building”) conducted by several developers. This is done for security and quility purposes, and can take up to several days.

If after about a week no problems are reported in the latest release candidate, Van der Laan will announce that this release candidate is now the actual new release. This new release is distributed through bitcoincore.org and bitcoin.org.

Estimated time: 1 week+

Step Five: The Activation

Once Bitcoin 0.12.2 is released, the Bitcoin Core development team will encourage everyone to upgrade. While upgrading is optional – older nodes will remain compatible with the rest of the Bitcoin network – upgraded nodes reap the benefits of Segregated Witness and retain maximum security.

But if only typical users upgrade, Segregated Witness will not yet activate. Activation will require miners to upgrade. As per Bitcoin Core 0.12.1 and the adoption of version bits, soft forks happen through a new type of signaling.

First, miners (or pools) running Bitcoin Core 0.12.2 (and Bitcoin implementations that merged similar code), automatically start signalling they are ready to mine Segregated Witness transactions. This happens through version bits they include in blocks they do mine that indicate what types of transactions and blocks they can mine. 

Once miners representing 95 percent of hash power (1,916 blocks) within a single difficulty period (2,016 blocks/about two weeks) include the right version bit, the soft fork is locked in. One difficulty period later, the soft fork is activated, meaning the remaining 5 percent of miners have about two weeks to upgrade. (If they don’t upgrade, they will remain part of the Bitcoin network, but could have their blocks orphaned by other miners if they include now-invalid transactions.)

Whether and how fast miners representing at least 95 percent of hash power will support Segregated Witness is hard to predict. As per the Hong Kong Bitcoin Roundtable Consensus letter, a vast majority of miners by hash power pledged to adopt Segregated Witness. 

But even that letter did not represent 95 percent of hash power. And slightly more than 5 percent of hash power is currently mining in favor of Bitcoin Classic; it’s not clear if the competing Bitcoin Core fork will merge Segregated Witness as well. (Nor is it clear if these miners will stick with Bitcoin Classic if it doesn’t merge Segregated Witness.)

Minimum time: 4 weeks

Step Six: The Adoption

After Segregated Witness is activated on the Bitcoin network, one final step is required for users to reap the benefits: Wallet software must include the option to actually create and receive Segregated Witness transactions.

How long it will take for wallets to adopt depends on their developers ‒ and on Bitcoin library developers. When Bitcoin asked wallet and library developers about this earlier this year, it seemed that most do plan to integrate Segregated Witness into their software. The pace at which this will happen might vary, however; some developers are more willing, better funded or simply more capable than others. Some made the necessary changes already and will support Segregated Witness from Day 1 of activation; others might take a bit longer.

But as long as there is at least one wallet offering the option, users can always switch and enjoy the benefits right away.

Estimated time: varies

 

Thanks to Bitcoin Core developers Eric Lombrozo and BTCDrak for feedback and technical guidance.

The post The Segregated Witness Timeline: From Idea to Adoption in Six Steps appeared first on Bitcoin Magazine.