Topic: [2016-09-14]Preparing for a Bitcoin Hard Fork (Read 446 times)

"Preparedness is important either way, Corallo said, but the unsuccessful ethereum fork pointed out further issues with hard forks that need more analysis.

Earlier this summer, ethereum enacted a change to its code after one of its more notable projects was compromised. The result was that the developers proposed a permanent divergence in its blockchain, scraping one bitcoin blockchain for an upgraded one.

A hard fork meant that every node – miners, merchants and users – had to upgrade to be able to validate the new blocks, but due to the controversial reason for the fork, a sizable minority chose not to make the switch.

The result is two development groups – ethereum and ethereum classic – both of which claim ownership over the vision for the "ethereum" project.

Given the risk that bitcoin could face from a similar split, there remains deep reservations among its developer community about whether a bitcoin hard fork should be discussed at all.

Scaling bitcoin

The tension on the subject has led to a larger debate on how best to change the bitcoin protocol, but "hard forks" aren't the only solution being discussed.

"Soft forks", for one, are backwards-compatible and self-correcting in that only a majority of miners need to update to the new consensus rules. Old nodes will then see the new blocks as valid.

In this case, not every user or node will need to update to accept the new consensus rules and continue validating transactions. (Note: There remains deep divisions about what constitutes a "hard" vs "soft" fork, with core developers even disagreeing on how to define past network issues in such terms).

Most of the conversation around hard forks so far has centered on Segregated Witness, a method originally proposed to fix transaction malleability that soon evolved into a way to scale bitcoin with a soft fork. The scaling mechanism will allow blocks with 2MB of data to be validated, up from the current 1MB limit, when implemented.

Yet, since the time it was proposed in December, the scaling debate has tapered off as other improvements have brought optimizations.

"Six months ago the network was in rough shape. The propagation across the network was really slow," Corallo said. "We've been optimizing a bunch of little places all over the place and that starts to make a big difference for people."

Because the Core developers have succeeded in optimizing the network through efforts like Corallo's Fast Internet Bitcoin Relay Network (FIBRE) and mempool size limiting, the network, in Corallo's view, is more able to handle small increases in the blocksize, which can come in the form of the Segwit upgrade without a hard fork.

That said, there remains a vocal contingent that remains committed to "on-chain scaling" that believes the bitcoin network, its user base and its businesses will not be able to sufficiently grow without more aggressive changes to the protocol that go beyond tweaks and upgrades to its exterior components."

While a bitcoin hard fork isn't imminent, its developers have begun to research how the complex technical change could be enacted, if needed.
The proactive steps illustrate the new responsibility Bitcoin Core, the network's mostly volunteer developer group, has taken on as the protocol has grown from the pet project of its mystery creator to a broad network of consumers, businesses and stakeholders.
As bitcoin remains the most widely used blockchain platform (one that many people see as having the greatest potential to change the way society transacts), this responsibility, the bitcoin developers argue, should be treated with caution and respect.
In this light, there has been a renewed emphasis within Bitcoin Core to explore how it could implement a hard fork, a type of protocol change that has proved a lightning rod for controversy during bitcoin's ongoing scaling debate and resulted in schisms in other blockchain networks.

http://www.coindesk.com/preparing-bitcoin-hard-fork/