The working group behind the Segwit2x bitcoin scaling proposal has announced that the first version of its code is now ready for review and testing.
As such, the release provides the market with a first look at the technology underlying one of the most broadly supported bids to enhance the network. Announced in May as an “agreement” that united miners and startups, Segwit2x is an alternative technology roadmap to one proposed by Bitcoin Core, the network’s open-source developer group.
It has since emerged as a frequent subject of praise, criticism and discussion.
However, in what could be a promising sign, Segwit2x could become a moderate option that helps to avoid a contentious network split, and it looks like it could end up being somewhat compatible with an alternative proposal, the user-activated soft fork (UASF) BIP 148, which, as coded, will activate on 1st August.
The news is notable because earlier this week any compatibility between the two proposals seemed less likely – a discordance that raised fears of a split of the blockchain into two competing assets.
The development became apparent on Wednesday, when bitcoin developer James Hilliard submitted a change request, along with a code change that would reduce the time it takes for mining pools to lock in the update.
On GitHub, Hilliard said:
“This should reduce the chance of a conflict with BIP 148.”
By reducing that time, mining pools will have one (or maybe two) three-day periods in which they can lock-in a controversial code change called Segregated Witness (SegWit) by signaling support using the SegWit2x software before the UASF occurs on August 1st. Though, it’s unclear if mining pools will decide to do so.
The request was well-received, being met with several ‘ACKs’ – developer shorthand for ‘agreed’, and a sign of approval.
Firmer timelines
The alpha release of SegWit2x includes a working version of the software, which combines two changes, the scaling optimization SegWit and an increased 2MB block-size parameter.
The increase to 2MB is now scheduled for three months after SegWit activates, according to an email from BitGo CEO Mike Belshe. Prior to this, it’s been less clear (even to some SegWit2x participants) when the 2MB hard fork would take place.
“Segwit2x development has been moving quickly according to plan, and the project is in good shape,” Belshe said, in the message to the working group.
The 2MB block size has long been a point of contention, partially because it could lead to a blockchain split if not everyone agrees to upgrade to the new blockchain code. Further, some in the industry have already suggested they don’t plan to.
However, SegWit2x has won the support of most major bitcoin companies and mining firms, in total representing over 80% of bitcoin’s hash rate. (Though it remains unclear how reliable this support will be owing partly to fatigue around the issue).
With the alpha version out, the wider community now gets to review and test the software. The release also includes a new bitcoin testnet that developers can use to put the software through its paces and identify any bugs.
Testing phase
Developers can trial the software using the new test network, called testnet5, for the next two weeks.
“We are planning to conduct rounds of testing against the new testnet5 including everyone from the working group who would like to participate,” BitPay senior developer Justin Langston said in another email to the working group.
The plan for these rounds is to simulate the code’s deployment lifecycle, from signaling support for SegWit to activating the 2MB block-size parameter.
These rounds of testing and review are aimed to help avoid any future network problems, such as, in a worst-case scenario, the loss of users’ bitcoin.
In the email, Langston wrote:
“My perspective is limited. We need your feedback on what tests would be essential for your company to adequately assess applicable risks and be prepared to deploy on livenet, signaling accordingly, when the time comes.”
Security loose ends?
Feedback on SegWit2x’s plan has already been rolling in.
One working group participant argued there is potential for ‘replay attacks’ in the event of a hard fork. Replay attacks, in the event of a split leaving the community with two bitcoin tokens, could allow users to accidentally spend their bitcoin on both networks.
This confusion happened last summer when ethereum split into two coins, leading some companies to lose money.
The participant argued that protection from this confusing and potentially dangerous issue is needed within Segwit2x’s code.
Some Bitcoin Core developers have also criticized Segwit2x’s development timeline as being too short, because it often takes a significant amount of time to catch all errors associated with bitcoin code changes. SegWit itself was tested for over a year before it was launched.
So far, though, SegWit2x developers haven’t skipped a beat, saying the project will continue to move forward along the original timeline, with the beta release scheduled for 30th June. On 21st July, users will be able to run and signal the fully vetted software, according to the group.
Disclosure: CoinDesk is a subsidiary of Digital Currency Group, which helped organize the SegWit2x proposal and has an ownership stake in both BitGo and BitPay.
Binary code image via Shutterstock