Will BlockChain Hard Forks Ever Be Safe?
Hard forks don’t have the best reputation, among the blockchain community.
One of the most intuitive approaches to upgrading the blockchain is also deemed the most dangerous. Blockchains are built on common rules and the easiest way to improve them they’ve found to-date are these forks. Developers have found the execution of these hard forks to be quite challenging.
While there have been some serious improvements since the hard fork debacle that split ethereum’s blockchain in two last year, developers are continually testing to improve the process. They want to gain a better understanding of the entire process to make each previous mishap a thing of the past.
Not all blockchains struggle with these transitions and even implement them on a regular basis. The anonymous cryptocurrency Monero is one that has them scheduled regularly. Cryptocurrency developers with a more conservative view agree this practice might be something more common in the future.
Bitcoin Cash has two hard forks on their horizons after they successfully split from Bitcoin in August. Both of these updates to their blockchain are scheduled to take place within the next two months.
Hard forks are becoming the new norm but that doesn’t stop developers from debating when they are “safest” to be implemented and how to alleviate their side-effects.
Last year in the Ethereum hard fork, users and companies lost money because of the sudden creation of two chains.
With this mechanism increasing in popularity over the ecosystem, developers are hard at work trying to make them smoother and safer to ensure users don’t lose any funds.
The big issue dangling in the air is the “right” way to execute these hard forks.
The “replay attack” which causes the blockchain to split in two, confuses the users and the software on which cryptocurrency to follow. The user ends up accidentally sending cryptocurrency on two blockchains when it was only meant to be sent on one.
Bitcoin Gold, another hard fork projected to launch in 5 days, claims that it will add replay protection to its code. Bitcoin cash, Bitcoin’s first hard fork in August has already made changes that protect against the potential split.
SegWit2x is the best-known hard fork as it’s gained support from many of the bitcoin leaders but it’s still on the fence about this topic. Developers behind this controversial proposal believe implementing protection would deter users as they won’t want to take the extra step in making the upgrade. They strongly believe their new hard fork will become the new bitcoin. Different developers still have their own ideas on the best way to deal with these attacks.
Simultaneously, other developers insist that adding certain protection against replay attacks will ensure that users don’t end up confused and lose money.
Mark Erhardt, a BitGo engineer, explains that the copies of bitcoin end up being identical leading to them using the same address format. Unintentionally, coins get stuck in the process because the same addresses are used and are being sent between two networks.
Erhardt, who moderates the Bitcoin Stack Exchange, an active forum to ask technical questions about the protocol, mentioned he sees questions about wrong funds being sent frequently on the site.
If bitcoin cash is sent to a bitcoin address, it is still possible to recover the 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.
In November, there is an anticipated hard fork and Erhardt thinks this confusion with bitcoin cash is a hint of what could come in future hard forks.
“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 in his interview, 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.
Yet, what’s less discussed is a way of wiping these attacks away entirely.
Luke Dashjr, a Bitcoin contributor, introduced a protocol that would make the blockchain naturally resistant to replay attacks, “hopefully ending the whole argument,” he wrote.
A bunch of different changes would need to be made to Bitcoin and the development of this of this caliber would take a decent amount of time.
Dashjr told CoinDesk that the change is “not likely” to be implemented with the Segwit2x fork, which is still likely someday in the future, t least if they continue with the hard fork methods.
There are also greater administrative questions and concerns.
Bitcoin and the blockchain is a system in which no one single person is supposed to have all the power. The main bulk of the debate with Segwit2x is that each side is in a power struggle for control on the technical direction in which Bitcoin is going. Due to these opposing opinions on systems, there is fear one group might become more influential.
MimbleWimble, who is launching a new blockchain next year, are having the same discussions amongst their developers as they plan on finally rolling out their new cryptographic tricks and are able to put them into practice.
As a safeguard against unexpected technical issues that might arise after their launch, MimbleWimble developers are considering the idea of allowing hard forks for a brief amount of time.
“We’re a young project and we may make mistakes both with technical and governance rules,” MimbleWimble lead developer Igno Peverell told CoinDesk in their interview.
Their solution, if using the hard fork at all, is only using this method for two years at max.
There was obviously pushback on this idea. Andrew Poelstra, a Blocksteam mathematician, and earliest Mimble advocate urges that there is “rarely a need” to use hard forks and it poses a serious “centralization” risk.
After communicating his concerns, though, Poelstra states that the best approach to these implementations might not be so black-and-white. Therefore, he seems open to limiting the developers’ abilities to carry out the hard forks to a shorter time frame.
Featured Image: twitter