Blockchain Forks Are All the Rage, But Can They Ever Be Safe?

Hard forks have earned a bit of a bad name.

Long portrayed as dangerous (or at least disruptive), the mechanism is also one of the more intuitive for upgrading blockchains. Quite simply, since blockchains are built on common rules, it can seem like the easiest way to improve them is to introduce new rules (or change existing ones) – and that's exactly what hard forks, one type of a wider variety of forks, seek to do.

But as developers have learned the hard way, executing them is a challenge.

So, while best practices have come a long way since a hard fork unexpectedly split ethereum's blockchain in two last summer, developers are still seeking a better understanding of the process, studying its nuances and testing how to execute safely.

That said, not all blockchains struggle with the transition. The anonymous cryptocurrency monero carries out hard forks on a regular schedule and even cryptocurrency developers who some view as more conservative agree the mechanism might have a place in the future.

Bitcoin cash, for example, successfully split off from bitcoin in August, with relatively few problems for the network's many users. Now, at least two bitcoin hard forks are on the way – both of which will take place in the next two months.

But while hard forks are growing more common, developers haven't stopped debating under what conditions they are safest to use – and how to mitigate their less-than-desirable side effects.

In ethereum's case last year, users and companies lost money because of the resulting "replay attacks" that exploited the sudden creation of two chains.

So, with demand for the mechanism increasing, developers from across the ecosystem are working to make hard forks smoother and safer, in an effort to ensure that users don't lose any funds or faith in the networks that protect them.

Protecting money

One issue is that the "right" way to execute a hard fork isn't so cut and dry.

The problem is that when a blockchain splits in two, users – and the software they use – can get confused about which cryptocurrency to follow. One example of this confusion is referred to as a "replay attack," where users can accidentally send cryptocurrencies on two blockchains when they only meant to send funds on one.

Bitcoin cash, bitcoin's first hard fork in August, made a change that protects against this problem and bitcoin gold, another upcoming hard fork with goals opposite to bitcoin cash, claims it will add replay protection also.

Still, different developers have different ideas of the best way to deal with these attacks. The developers behind Segwit2x, perhaps the best-known proposed hard fork (since it's garnered support from many bitcoin industry leaders), have flipped back and forth on the topic.

Developers behind the controversial proposal maintain that the hard fork will become the new bitcoin and that implementing protection would deter the project since users will have to take the extra step to upgrade their software.

Post-fork confusion

Meanwhile, others argue that adding protection against replay attacks will ensure users don't get confused and accidentally lose money.

BitGo engineer Mark Erhardt (aka Murch) explained that since bitcoin cash is a copy of bitcoin in many ways, it uses the same address format. Since the addresses are of the same type, it's possible to send bitcoin between the two networks, where they then get stuck.

Murch, who leads moderation of Bitcoin Stack Exchange, an active forum to ask technical questions about the protocol, mentioned that he's seen "numerous questions" about this issue from users who accidentally sent funds to the wrong network.

If users send bitcoin cash to a bitcoin address, it's possible to recover funds by importing the corresponding bitcoin private key into a bitcoin cash wallet. On the other hand, if a bitcoin cash user sends bitcoin cash to a bitcoin SegWit address, it might be "lost altogether," he said.

Murch said that he thinks this confusion with bitcoin cash is a sign of what could come in future hard forks, like the one in November.

"There will be numerous incidents of users sending funds accidentally on both chains or from addresses of one chain to the other," he told CoinDesk, adding that one way to get rid of this problem would be for future forks to use a different address format.

"I am expecting a significant increase in support requests," he added.

Governance questions

Still, what's been less discussed is that there might be a way of wiping this attack vector away entirely.

Bitcoin Core contributor Luke Dashjr recently reintroduced a proposal that would make bitcoin naturally resistant to replay attacks, "hopefully ending the whole argument," he wrote.

This sort of development takes time, though, and will require a couple of different changes to bitcoin.

Dashjr told CoinDesk that he thinks the change is "not likely" to be implemented in time for the Segwit2x fork in November, although it might be implemented some day in the future. At least, if the bitcoin hard forks continue.

Then there are also broader governance questions and concerns.

You could say that this makes up the bulk of the argument around Segwit2x, as each side frames the debate as a power struggle for control of the technical direction of bitcoin. And there is a broader worry that hard forks could make certain groups more influential in systems where no one is supposed to have power.

These questions came to light in recent discussions among developers of MimbleWimble, as its developers plan to finally put its novel cryptographic tricks into practice by launching a new blockchain next year.

In the early stages, the developers are still working out the code and cryptography, so they are mulling over the idea of allowing hard forks for a short grace period, as a safeguard against unexpected technical problems that might pop up soon after the launch.

"We're a young project and we may make mistakes both with technical and governance rules," MimbleWimble lead developer Igno Peverell told CoinDesk.

The developer suggested a novel approach, though: putting an end to the upgrading mechanism after two years.

Some were skeptical of the idea. Blockstream mathematician Andrew Poelstra, one of the earliest MimbleWimble advocates, argued that hard forks pose a "centralization" risk and there's "rarely a need" to use one.

After expressing those concerns, though, he hinted that the best approach might not be so black-and-white, seeming open to the idea of limiting developers' ability to execute the type of upgrade to a shorter time frame.

He wrote:

"I like the idea of being clear upfront that the 'early days' won't last forever."

Seatbelt image via Shutterstock