Could two of bitcoin’s more polarizing scaling proposals unite?
As demand for alternative blockchain assets continues to grow, some technologists are starting to wonder if a more collaborative means of solving one of the network’s long-perceived problems could be achieved.
The idea is that two of the better-known scaling proposals, SegWit2x and BIP 148, might be equipped to work together given that both are attempting to upgrade the network with Segregated Witness (SegWit), a network optimization first proposed by developers in 2015.
Yet, each project is currently paving the way for a scaling optimization differently, and in ways that are ultimately incompatible with the other.
BIP 148, for example, is moving ahead with its user-activated soft fork (UASF) that would seek to push SegWit live without explicitly asking miners for support. SegWit2x, meanwhile, plans to pair SegWit with a 2 MB block-size increase, boosting transaction capacity further by tweaking the bitcoin’s underlying rules.
And that collision could lead to a split – one that turns bitcoin into two competing assets. Adding to the drama is that the upgrades are set to take their next steps at around the same time.
If all goes according to plan, users will be able to begin running SegWit2x on 21st July. Likewise, BIP 148 will be triggered on 1st August, an event some are calling “Bitcoin Independence Day”. Yet, because of the incompatibility between the two proposals, those that begin running SegWit2x could end up on an entirely different bitcoin network than those running BIP 148, with entirely different bitcoins trading at an entirely different value.
So, how likely is this more adversarial scenario?
Advocates of BIP 148 are saying their proposal is going to activate no matter what. Since people are already running the code for the bitcoin improvement protocol, there’s no way to alter it or put it back in ‘Pandora’s box’. So, with that in mind, several developers have argued that SegWit2x should adopt BIP 148 to avoid a split.
John Light, who works with bitcoin payment startup Abra, is one of those advocates, contending in a recent blog post that “BIP 148 does not violate the of the [SegWit2x] agreement, since it both activates SegWit and in no way prevents signatories from running code for a 2MB hard fork once it’s ready”.
The idea is that, if the goal is activating SegWit, then why not join forces rather than risk a split?
Light told :
“That will ensure that there are no more unnecessary delays in activating SegWit. The sooner we get SegWit, the sooner the 2 MB hard fork is activated.”
But, there are other ideas for keeping the network from splitting up.
Bitcoin developer James Hilliard recently proposed ‘split protection’ that requires less miner support for SegWit than past proposals. Effectively, if a majority of miners run it a split would be avoided.
“I think split protection could be the closest we get to a ‘golden ticket’ to maximize compatibility between BIP 148 and Segwit2x,” Reddit moderator BashCo said, echoing the sentiments of some other bitcoin developers.
BashCo could be right, but it’s hard to say what will happen given that there’s some resistance to BIP 148 in the bitcoin community.
When asked whether SegWit2x would be compatible with BIP 148, Bloq co-founder Jeff Garzik, one of the developers who’s been leading the charge to SegWit2x, didn’t suggest this was a top priority.
Garzik told :
“We’re really trying to stay laser-focused on what the participants agreed to, building, testing and getting review for that: SegWit + 2MB hard fork. As a general rule, we want to avoid scope creep.”
‘Scope creep’ seems to have already become a problem for the project. On its GitHub pages, Garzik has waved off various requests for a variety of extra features given the short time frame he was assigned for the project.
Still, he has been open to feedback – seemingly in favor of incorporating another proposal, BIP 91 (from Hilliard), aimed at ensuring that SegWit2x’s implementation is compatible with the estimated 83% of bitcoin nodes that are already running the version of SegWit that was deployed last November.
Plus, SegWit2x is an open-source project, meaning it relies on input from volunteers. The alpha version will be released this week, on 16th June, at which point outside developers can leave additional feedback.
So many forks
Adding to all the complexity here is that each proposal on its own might result in some users forking off onto their own network.
If a majority of mining pools don’t flag support for SegWit, BIP 148 will lead to the creation of two separate bitcoin assets. Meanwhile, if users decide not to upgrade to 2MB, SegWit2x will lead to a split as well.
Now, more than ever, there seem to be more efforts that could lead to splits, which is one reason why this current group of proposals have vehement detractors.
Still, while the thought of a split is worrisome to many stakeholders, bitcoin’s scaling debate has seen plenty of false alarms. In the past, other developers and users have suggested they would like to split off from bitcoin, but none, so far, have actually followed through.
Blockstream chief strategy officer Samson Mow, for one, doesn’t think it’s possible to mandate that all users uphold the hard fork portion of the SegWit2x agreement – the part that could lead to a split. Other developers have argued that it’s impossible to mandate that everyone switch to the 2MB version at a technical level.
Because of these technical complications, some in the community doubt that the companies that signed on to the SegWit2x proposal will see through with making the 2MB upgrade.
“Basically it’s a promise that can’t and won’t be kept,” Mow argued.