Hard forks have earned a bit of a bad name.
Long described as dangerous (or at least disruptive), the mechanism is also one of the most intuitive to modernize blockchains. Just because blockchains are built on common rules, it may seem that the easiest way to improve them is to introduce new rules (or modify those that already exist) – and that is exactly what the forks are looking for. to do.
But as developers have learned the hard way, running them is a challenge.
So, while good practices have come a long way since a hard fork unexpectedly split the ethereum blockchain in two this past summer, developers are still looking for better understanding the process, study its nuances and test how to run safely.
That said, all blockchains do not fight with the transition. The anonymous cryptocurrency monero runs hard forks on a regular program and even cryptocurrency developers that some consider more conservative agree that the mechanism might have a place in the future.
Bitcoin Cash, for example, was successfully split from Bitcoin in August, with relatively few problems for many network users. Now at least two bitcoin forks are on the way – both will take place in the next two months.
But as forks become more and more common, developers have not stopped debating under what conditions they are the safest to use – and how to mitigate their less than desirable side effects.
In the case of the Ethereum last year, users and businesses lost money because of the resulting "replay attacks" that exploited the sudden creation. two chains.
As the demand for the mechanism increases, developers from across the ecosystem are working to make the forks smoother and safer, to ensure users do not lose funds or trust in the networks that protect them.
Protecting Money
One problem is that the "good" way to run a hard fork is not as well cut and dry.
The problem is that when a chain of blocks splits in two, the users – and the software they use – can get lost in the cryptocurrency issue to follow. An example of this confusion is called "replay attack", where users can accidentally send cryptocurrencies on two blockchains while they only wanted to send funds to one.
Bitcoin Cash, Bitcoin's first hard fork in August, brought a change that protects against this problem and Bitcoin Gold, another upcoming fork with objectives opposed to Bitcoin Cash, says that it will also add a protection against replay.
Yet, different developers have different ideas on how best to handle these attacks. The developers of Segwit2x, perhaps the most well-known hard drive proposed (as it has got the support of many leaders in the bitcoin industry), have gone back and forth on the subject.
The developers behind the controversial proposal maintain that the hard fork will become the new bitcoin and that implementing the protection would discourage the project as users will have to take a step further to update their software.
Post-fork confusion
Meanwhile, others argue that adding protection against repetition attacks will ensure that users will not get lost and accidentally lose money.
The BitGo engineer Mark Erhardt (aka Murch) explained that bitcoin cash is a copy of bitcoin in many ways, it uses the same format of address. Since the addresses are of the same type, it is possible to send bitcoins between the two networks, where they are blocked.
Murch, who leads the moderation of Bitcoin Stack Exchange, an active forum for asking technical questions about the protocol, mentioned that he saw "many questions" about this problem from users who accidentally sent funds to the wrong network.
If users send cash bitcoin to a bitcoin address, it is possible to recover funds by importing the corresponding bitcoin private key into a bitcoin cash portfolio. On the other hand, if a bitcoin user sends bitcoin money to a bitcoin SegWit address, it could be "completely lost," he said.
Murch says that he thinks that this confusion with bitcoin money is a sign of what could come in the coming bands, like November's.
"There will be many incidents of users sending funds accidentally on both channels or addresses from one channel to the other," he said. CoinDesk, adding that one way to get rid of this problem would be different address format.
"I expect a significant increase in requests for support," he added.
Governance Issues
Yet, what has been less discussed is that there could be a way to completely erase this attack vector.
Bitcoin Core collaborator Luke Dashjr recently reintroduced a proposal that would make bitcoin naturally resistant to repetition attacks, "hoping to end all the argumentation," he writes.
This kind of development takes time, however, and will require some different bitcoin changes.
Dashjr told CoinDesk that he thought the change was "not likely" to be implemented in time for the Segwit2x fork in November, although it could be implemented a day in the future. At least, if the bitcoin forks continue,
Then there are also more general questions and concerns about governance.
One could say that this is the bulk of the argument around Segwit2x, as each side frames the debate as a power struggle for control of Bitcoin's technical direction. And there is a more general concern that hard forks could make some groups more influential in systems where no one is supposed to have power.
These questions have been uncovered in recent discussions between developers of MimbleWimble, as its developers plan to put its new cryptographic tricks into practice by launching a new blockchain next year.
In the early days, developers are still working on code and cryptography, so they are thinking about allowing forks for a short period of grace, as a protection against unexpected technical problems that might arise shortly after launch.
"We are a young project and we can make mistakes with both technical and governance rules," said MimbleWimble lead developer Igno Peverell at CoinDesk.
The developer, however, suggested a new approach: to end the upgrade mechanism after two years.
Some were skeptical of the idea. Andrew Poelstra, mathematician of Blockstream, one of the early advocates of MimbleWimble, argued that the hard forks pose a risk of "centralization" and that it is "rarely necessary" to use one .
After expressing these concerns, however, he suggested that the best approach may not be so dark, seemingly open to limiting the ability of developers to run the upgrade type more. quickly.
He wrote:
"I like the idea of being clear from the outset that the" first days "will not last forever."
Seat Belt Image via Shutterstock
Leader in blockchain information, CoinDesk is an independent media company that strives to achieve the highest journalistic standards and adheres to a strict set of editorial policies. Do you want to offer your expertise or ideas for our reporting? Contact us at news@coindesk.com.