Immature Code or Good Test? Bitcoin Scaling Proposal Segwit2x's Testnet Forks

Controversial bitcoin scaling proposal Segwit2x's testnet forked yesterday, creating two different and incompatible testnets.

Nodes running older bitcoin software continued on as they normally would. But nodes running the new Segwit2x code stalled at block 27070, meaning mining pools running the new software were not mining blocks.

Overall, the nodes were stalled for over 20 hours as a result of the issue.

While there wasn't any real money on the line, the community was abuzz with the news, some dismissing the controversial scaling proposal for perceived lingering issues, while others defended the misstep as only a small stumbling block that wouldn't happen during a live deployment.

Too little, too late

Some developers argue the fork is a symptom of a larger trend of Segwit2x developers not listening to other developers who have worked with the bitcoin code for a long time. Bitcoin Core developers, for example, have provided feedback, pointing out perceived errors, but some of that has been ignored.

On social media, some argued the testnet fork stemmed from the implementation of the 2MB hard fork developers discussed and disagreed upon a couple of weeks ago.

The 2MB hard fork is the second part of the Segwit2x proposal, an effort to double the block size parameter, which will happen three months after the Segregated Witness (SegWit) activation.

This second part is important in that if not everyone in the bitcoin ecosystem upgrades to the 2MB increase (and many say they don't plan to), bitcoin could split into two assets. If that split is not made permanent, one chain could "wipeout" transactions that occur on the other chain, potentially leading users to lose money.

On the project's GitHub, developers had different ideas of how to solve that.

Segwit2x went forward with software that requires at least the first block is greater than 1MB. Some contend this is what lead to the testnet fork, since there weren't enough transactions in the mempool, the part of the network where transactions are collected before being selected for blocks.

Bitcoin developer James Hilliard had proposed what he calls a "simpler and better" way of implementing so-called "wipeout protection," where nodes insert a piece of data making their blocks invalid to the other network.

Still, given that it's slated to be deployed in two weeks, for many, the bottom line is that it's too late for the code to have serious issues.

Working group members are expected to install and test the code this Friday. Then, mining pools, companies and users are expected to begin running the code on the main bitcoin network as soon as July 21.

Jokers to blame

But Bloq co-founder and BTC1 developer Jeff Garzik argued the fork is not an event to worry about. One of the testnet miners simply triggered an event sooner than planned and without preparation from the working group participants, he said.

According to Garzik, this split wouldn't happen once Segwit2x is deployed on the main bitcoin network.

He told CoinDesk:

"It falls into the category of 'jokers can disrupt test networks, because test networks have very little mining power security.'"

BTC.com's Boaz Bechar, who's also working on the Segwit2x implementation, offered a similar explanation.

While the testnet isn't expected to have many transactions flowing through it, the main bitcoin network will.

"Although unexpected timing, this is otherwise a good field test," Garzik wrote on the Segwit2x working group mailing list. "This is the whole reason for a test network, after all."

Disclosure: CoinDesk is a subsidiary of Digital Currency Group, which helped organize the Segwit2x agreement.

Lollipop image via Shutterstock