Bitcoin's 'Segwit2x' Scaling Proposal: Core Developers Strike Critical Stance

Days after a widely-supported but contentious proposal for increasing bitcoin's transaction capacity was unveiled, technical details about the plan are coming to light.

It might not be particularly surprising if you're very familiar with bitcoin's long-standing block-size debate, but the tentative code for what's now known as 'Segwitx2' hasn't been especially well-received by the project's open-source developer community.

One so-called pull request from Bloq co-founder Jeff Garzik, for example, was greeted with a chorus of skeptical comments. Most were rather technical, coming from some developers who have worked on bitcoin for a long time, but the response seemed to boil down to: 'Why isn't the group using a safer method – one that many of us suggested earlier on?'

Some of the comments seemed to carry a mocking tone. "This pull request is quite odd," Colu blockchain research lead Udi Wertheimer stated in his reply.

"There are still no tests," another developer stated simply.

Still, Garzik, a former Bitcoin Core developer employed by bitcoin processor BitPay, welcomed the feedback, and later in the day, he responded on Medium. "This was a starting point," he said, indicating his stance that the current implementation on GitHub is meant to be a work in progress.

Garzik added that he agrees with the feedback received and endorses making changes that enable the code to be compatible with the existing version of Segregated Witness (or SegWit) – a plan to scale the blockchain proposed by Bitcoin Core contributors in 2015.

"If the outcome maximizes compatibility even more, re-uses existing testing even more, that is a win. Forward progress," Garzik wrote.

Fork fears

Yet for all the implied derision, this developer debate could be viewed as an example of 'collaboration' and peer review.

It's probably worth noting that none of the volunteer developers behind Bitcoin Core signed the ‘agreement’ on the proposal, first announced by investment portfolio company DCG last week. As hinted in the concerns above, this was partly because of technical concerns, and partly because some don't believe that a hard fork is necessary right now.

Capacity increases beyond SegWit, some argue, can be brought about in other backwards-compatible ways that don't risk kicking some network participants out of the system.

Once the proposal was released, and even long before then, developers had given technical feedback about how best to deploy a hard fork, which might explain a hint of bitterness from developers in recent discussions.

But, even if many of them aren't keen on details of the proposal, so far that hasn't stopped developers from trying to improve the implementation.

"I wrote BIP91 to try and make the proposal more sane," said bitcoin developer James Hilliard, adding that, in his eyes, the current hard fork timeline is "completely unrealistic".

Others put more weight behind the proposal, which has backing from more than 60 companies and more than 80% of bitcoin's mining pool operators and firms.

"I think we should look to build from the proposal and improve it," Blockstream CEO Adam Back said. Overall, Back has emerged as perhaps one of the more positive voices, with comments suggesting pushback from developers could create perception issues.

In particular, he's trying to steer interest toward a proposal called 'spoonnet', a branch of hard fork research from Bitcoin Core contributor Johnson Lau.

Bitcoin Core contributor Eric Lombrozo, who worked on SegWit code, had a similar collaborative take. "I will work hard with [DCG founder and CEO Barry Silbert] to make this a success," he wrote on social media, though not without some caveats.

Too much, too soon?

The bottom line, though, is that many developers don't think the proposal is a good one.

Bitcoin Core contributor Bryan Bishop summed up the concerns the most succinctly:

"I think that ultimately the [DCG] hard-fork is going to fail to safely transition the entire network. There's no replay protection. It's an unreasonably short timeline. It doesn't make use of the prior hard-fork research efforts."

"I think the entire industry needs to wake up and realize how long these things take," he added, arguing that peer review and testing takes a long time. (Other developers and bitcoin users have also questioned the six-month timeline.)

Perhaps the more important question though is: if the group addresses these technical concerns, would more developers support it?

The response, as usual, was complicated and mixed, with some expressing a desire to consider all the tradeoffs.

"There's a general sentiment among Bitcoin Core developers that a tremendous amount of capacity can be gained by soft forks and backwards-compatible upgrades. I don't think that Bitcoin Core developers are going to rally around a hard fork in the near future, especially not one dictated by a closed-door secret meeting," Bishop said.

Developer Jonas Schnelli, known for the libbtc library, said he could possibly get behind a hard fork for a block-size increase if given more time.

"I’m happy with SegWit2x if it could reduce to 80% without being incompatible to the existing [SegWit] implementation," Schnelli said. "And do the [hard fork] later."

Others simply don't think that it will work, seeming to treat it with the same interest as they treated Bitcoin XT or Bitcoin Classic – other hard fork proposals that failed (although this new effort has garnered more support).

Other options

Many developers expressed the sentiment that transaction capacity could be increased in other, perhaps safer, ways. For one, some tend to think that SegWit is a better solution on its own – without the accompanying hard fork, which could lead to a network split.

"On SegWit2x, there is no technical reason to couple [Segwit] with a [hard fork]. Only political. And bitcoin was created to stay away from politics … this is why I mainly [do] not support it,” said Schnelli.

Bitcoin Core contributor Luke Dashjr was open to yet another recent proposal, called COOP, which combines a bunch of hard-fork research into one bitcoin improvement proposal (BIP), for safer deployment. But, he had reservations about increasing the block size so quickly.

Dashjr has actively promoted BIP148, a controversial backwards-compatible mechanism that’s been gaining momentum and that also has a deadline for activation, though some worry it too could result in a chain split.

He concluded:

"Either way, BIP148 begins in August."

Disclosure: CoinDesk is a subsidiary of Digital Currency Group (DCG).

Man on construction ladder image via Shutterstock