A group of contributors to the open-source Bitcoin Core development project met late last month in Switzerland for a sit-down review of the code for Segregated Witness, a proposal aimed at scaling the bitcoin network.
The gathering in Zürich drew about 20 Core developers, and comes at a time when there remains deep divisions in the community over the actions of the group, as well as its approach to scaling the bitcoin network.
In this light, the meeting in Zürich had a certain gravity, given that the work being performed will have major implications for the bitcoin network’s trajectory in the months and years ahead. The Segregated Witness proposal follows discussion going back to mid-2015, though the broader question of scaling the bitcoin network has long been debated by developers.
It’s a process that isn’t without risk. The contributors to Bitcoin Core are perhaps best viewed as the guardians of as much as $9bn in value denominated in bitcoin. As the network is run on the code published by Bitcoin Core, a foul-up could expose users and their money to security risks.
This is not to say that the issues aren’t borne in mind by those contributing to the project, and the Segregated Witness proposal in particular.
In interview, contributor Eric Lombrozo said that the process of integrating SegWit into Bitcoin Core “is pretty high-stakes”, while at the same time defending the team’s position on scaling the network as a necessity to avoid technical problems.
Lombrozo argued that the soft fork approach to rolling out SegWit is the safer option, telling CoinDesk:
“It’s a difficult challenge to [hard fork] without destabilizing the network. A very difficult challenge.”
Sit-down in Zurich
According to Lombrozo, the group wanted to avoid making any concrete decisions during the face-to-face meeting, both in terms of SegWit as well as broader development matters, leaving that to the community’s mailing list and chatroom-based meetings where the decision-making process is public.
This point was emphasized in remarks by contributor Jonas Schnelli, who advocated for this direction at the outset of the event, according to notes published by the Core team.
“Don’t feel too pressured to make code-based progress,” Schnelli said. “That we’re able to sit together in one room and try to work together as a team is the value itself.”
This sentiment is perhaps a response to a central criticism levied against Core in the past – that it operates above or beyond the scrutiny of community members and stakeholders, particularly those who have called for an increase in the overall size of bitcoin transaction blocks. It was this argument, in part, that fueled work on alternate software versions like Bitcoin XT and, later, Bitcoin Classic.
Lombrozo, in conversation, pushed back against the idea that development on bitcoin has diverged from the interests of its users, arguing that he believes the team will exceed expectations at launch.
He continued:
“The last year has seen this narrative arise that progress on tech is stagnant. This narrative was partly due to price stagnation… but also encouraged largely by a huge misunderstanding regarding what Core actually does and how Core functions.”
Code review
Yet in recent months the volunteer community has sought to reposition its development and communication processes to be more inclusive, something that began after tensions flared amid a perceived lack of progress earlier this year.
According to Core contributor Bryan Bishop, the in-person review in Zürich provided an opportunity for programmers to focus on work and dig more deeply into the code itself.
Effectively, those involved in the review would raise questions or concerns, which would then be put to whichever point person was involved with that aspect of development.
He told CoinDesk:
“Once each person is sufficiently convinced that outstanding issues have been resolved, they can proceed to other sections of the proposed change and continue this process. Each person has slightly different criteria for how thoroughly they think will check each portion of SegWit, and in combination between multiple people this means lots more coverage over each aspect of the proposed changes.”
This, he suggested, was an extension of the work already being performed today across the Core team’s online communication channels, including open-source chat protocol IRC and the bitcoin development mailing list.
Bishop further indicated that the team was able to identify a number of small issues present in the code.
“At the gathering, SegWit code review went pretty well. I believe there were a handful of trivial bugs found and fixed,” he said.
Moving forward
For now, those involved with the project say they’re focused on finalizing the code for SegWit, though no timetable has been given for its launch.
“I think we’re getting close to the point where we feel comfortable [launching] it,” Lombrozo said. “There’s just a few edge cases that still might need testing, or it’d be nice to have more people running it just to make sure we have more people giving us feedback on it.”
While indicating that those working on the upgrade “want to merge SegWit as soon as possible”, such a launch would only follow a period of robust testing that has been ongoing for months, Lombrozo said.
“A big thing was asked of us…and I think what we’re delivering will be even better than what people thought not that long ago,” he added.
Given the stakes – upgrading a globally distributed network of computers is no easy task – the next steps could prove pivotal not only for Core group of developers, but the future of the bitcoin network itself.
Though some in the community may not agree with its approach, all eyes will be on the Core team as SegWit inches closer to launch.
Correction: This article has been amended to clarify the context of a quote by Core contributor Eric Lombrozo.
Image via Shutterstock