SegWit2x new code released today, 2MB hard fork part still has not reached internal consensus

SegWit2x, a controversial scaling proposal supported by the vast majority of bitcoin businesses and miners, is moving forward according to a previously announced timetable.

In an email yesterday, Bloq co-founder and SegWit2x lead developer Jeff Garzik confirmed to CoinDesk that the new code is expected to be released this Friday, after two weeks of alpha testing. This code release is said to address some issues encountered in the initial version.

As such, this release is expected to mark a new phase for the proposal. SegWit2x has been praised by some as a practical solution for bitcoin scaling, but has also been criticized as a protocol that misunderstands the nature of bitcoin development and the design of the network.

Regardless, SegWit2x is unique, especially given that it has the most support from Bitcoin businesses and mining pools ever. Moreover, the overwhelming support from miners means that if the SegWit2x code is released, it will have the necessary hashrate support to activate it.

If development continues as planned, SegWit, the Bitcoin scaling optimization solution, could be activated by August, with a hard fork three months after activation to increase the block size from the current 1MB to 2MB. However, the change remains controversial and has been criticized.

Testing Phase

So far, there is relatively little public information available about the SegWit2x testing phase.

According to SegWit2x participants, the past two weeks of SegWit2x development have been focused on testing, with companies using a new test network (testnet5) and a so-called "faucet" for releasing fake bitcoins to the test network.

One notable change this week was that the development team temporarily adjusted the details of the hard fork portion of the SegWit2x protocol.

Companies involved in the project — including Abra, Bitfury, Blockchain, BTCC, OpenBazaar, Purse and Xapo — have been contributing to development and testing, though there have been no public announcements about the details of the work.

Looking at the SegWit2x Github site, it’s clear that developers have been testing the code. For example, Purse CTO Christopher Jeffery has identified and fixed a number of bugs over the past two weeks, while others have come up with other ideas.

Some companies are playing a similar role. For example, Chris Pacia, lead backend developer at OpenBazaar, said he is the only developer at the company who contributes to the project. He explained that he created a testnet5 DNS seed (to help new nodes connect to the test network) and occasionally provides feedback.

However, the handful of companies that pledged to help test the code have been reluctant to respond to requests for comment on their involvement. (Some critics have even argued that the companies involved are attempting to “corporatize” bitcoin, asserting that SegWit2x is an attempt by a small group of companies to manage the decentralized web currency.)

The remaining questions

So, with SegWit2x Beta testing around the corner, what’s next?

According to the schedule, mining pools supporting SegWit2x intend to begin installing the software on July 14, which can then be used to signal support for the SegWit upgrade after July 21.

Last week, mining pools representing 80% of the network's hashrate agreed to run code that could lock in SegWit by July 31. Then three months later, the 2MB hard fork would be automatically activated. It is worth noting that if not everyone agrees to upgrade their software to support the change, this hard fork could cause Bitcoin to split into two competing tradable Bitcoin assets.

Although this is planned for after the summer, Bitcoin developer James Hilliard mentioned that the details of the 2MB hard fork are still being discussed.

He told CoinDesk:

“The details of the 2MB hard fork are still unclear.”

Hilliard, who contributed code to SegWit2x, expressed skepticism about the timeline for the hard fork, calling it “unrealistic” — a view shared by Core developers, who are almost collectively opposed to the SegWit2x project.

Developers have proposed a variety of hard fork approaches, and Hilliard said it may still require waiting and completing the code and organizational work to increase the block size after SegWit is activated.

As always, users will have to wait and see how things unfold, and can only speculate on possible outcomes and impacts at this point.